[
https://issues.apache.org/jira/browse/LUCENE-4885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624928#comment-13624928
]
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 level...
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: https://issues.apache.org/jira/browse/LUCENE-4885
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
