lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] [Commented] (LUCENE-4885) each FacetResult should return the facet equivalent of totalHits
Date Sun, 07 Apr 2013 14:41:15 GMT


Shai Erera commented on LUCENE-4885:

I hear you. That's why I first, too, thought it should be on FacetResult, and that we can
just use numValidDescendants. I'm torn here too, not sure what to do about TopKInEachNode.
I guess that we could resolve this by separating FRN and TreeFRN, while FRN recording ordinal,
value and label and TreeFRN recording subResults and uniqueChildrenCount? The problem is how
to iterate on the results...

Hmm, maybe the cut needs to be higher up at FacetResult level, with FacetResult (flat) and
HierarchicalFacetResult. FacetResult will give you an Iterator<FRN> and if it's Hierarchical
or TreeFacetResult), you get in practice an Iterator<TreeFRN> ... also, FR will record
uniqueChildrenCount. For TreeFR this can mean the total unique count, or just at the root

Today, for the common case, we spend a List pointer at each FRN, which is null. Perhaps, as
you say, it's usually a non issue since you ask for a low K ...

One other solution would be to hide the uniqueChildrenCount and subResults behind methods,
so that FRN returns -1 and null, while TreeFRN implements them accordingly?

In general, I feel that FacetResult and FRN are too verbose. I think that the root node's
statistics could be available from the FacetResult level, and that it could give you an iterator
directly, rather than giving you a node which you always *must* call root.subResults... but
it's for a separate issue.

Regarding TopKInEachNode, I wonder if we should eliminate that completely from FacetRequest,
and create an appropriate FacetResultHander which you configure with the levels that you want,
including (potentially, in the future) different K values for different levels?
> each FacetResult should return the facet equivalent of totalHits
> ----------------------------------------------------------------
>                 Key: LUCENE-4885
>                 URL:
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>              Labels: newdev
>             Fix For: 5.0, 4.3
>         Attachments: LUCENE-4885.patch, LUCENE-4885.patch
> This is cheap to compute, since the TopKFRH already must visit all non-zero-count ords
under the FacetRequest.categoryPath.
> This can be useful to a front end, eg to know whether to present a "More..." under that
dimension or not, whether to use a suggester like LinkedIn's facet UI, etc.

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:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message