The thing is that there are two dimensions here: CategoryListParams and OrdinalPolicy for a category dimension:
- Different CLPs are good for when an application has good reasons to group different categories into different category lists, and then at search time request different groups of facets. E.g. an eCommerce application will probably have different facets for Cameras and Shoes, and therefore it would make sense to separate the facets into different lists.
- However, Mike and I saw that when you index hierarchical facets, then indexing them as NO_PARENTS yields better performance than ALL_PARENTS (b/c e.g. less ordinals are read), even when the parents' counts are rolled up in the end.
- Having said that, we also experimented with separating dimensions to separate field (one field per dimension), but that yielded worse results than grouping them together.
- So on one hand we want to have different OrdinalPolicy for different dimensions, but on the other hand, still group categories under the same CLP.
When I started to work on that issue, I did just like as you suggest – use PerDimensionIndexingParams, and pass different CLP instances for different dimensions, yet still keep the CLP.field the same for dimensions that "should go together".
But that complicated matters for FacetFields, b/c it first groups all CPs under their respective CLPs, and creates a Map<CategoryListParams,Iterable<CategoryPath>>. Then all the CPs of the same CLP are passed to CountingListBuilder.
If I wanted to work w/ PerDimensionIndexingParams, I'd need to change FacetFields to map from a String -> (map of CLP -> CP) and then change CountingListBuilder accordingly. Also, CountingFacetsCollector would need to change as well, since currently it assumes a single CLP instance.
In short, while this is doable, I think it's confusing, and could lead apps to think that if you need different OrdinalPolicy for dimensions, you also need different CLPs, and consequently different fields, which is bad!
So I think that solution is good – whoever intends to control OrdinalPolicy, would need to create some Map, so with this approach, he'll create a Map(String,OrdinalPolicy). If he needs both worlds (multiple CLPs AND OrdinalPolicy-ies), then he needs to create two Maps ... doesn't sound a big deal to me.