[
https://issues.apache.org/jira/browse/LUCENE-4715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565385#comment-13565385
]
Shai Erera commented on LUCENE-4715:
------------------------------------
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.
> Add OrdinalPolicy.NO_DIMENSION
> ------------------------------
>
> Key: LUCENE-4715
> URL: https://issues.apache.org/jira/browse/LUCENE-4715
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/facet
> Reporter: Shai Erera
> Assignee: Shai Erera
> Attachments: LUCENE-4715.patch
>
>
> With the move of OrdinalPolicy to CategoryListParams,
> NonTopLevelOrdinalPolicy was nuked. It might be good to restore it, as
> another enum value of OrdinalPolicy.
> It's the same like ALL_PARENTS, only doesn't add the dimension ordinal, which
> could save space as well as computation time. It's good for when you don't
> care about the count of Date/, but only about its children counts.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
