[
https://issues.apache.org/jira/browse/LUCENE-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038605#comment-13038605
]
Michael McCandless commented on LUCENE-3097:
--------------------------------------------
{quote}
bq. I think you need to hold the docBase from each setNextReader and re-base
your docs stored in the GroupHead?
I think I'm doing that. If you look at the updateHead() methods. You see that I
rebasing the ids.
{quote}
Ahh excellent, I missed that. Looks good!
{quote}
bq. Once docs within one can have different values for field X then we need a
different approach for counting their facets...
But that would only happen when if an update happen during a search?
Then all collectors can have this problem, right?
{quote}
This is independent of updating during search I think.
I don't think the existing collectors have a problem here? Ie the
grouping collectors aren't normally concerned w/ multivalued fields of
the docs within each group.
It's only because we intend for these new group collectors to make
"post-grouping facet counting" work in Solr that we have a problem.
Ie, these collectors won't properly count facets of fields that have
different values w/in one group?
Say this is my original content:
{noformat}
name=3-wolf shirt
size=M, color=red
size=S, color=red
size=L, color=blue
name=frog shirt
size=M, color=white
size=S, color=red
{noformat}
But, I'm not using nested docs (LUCENE-2454), so I had to fully
denormalize into these docs:
{noformat}
name=3-wolf shirt, size=M, color=red
name=3-wolf shirt, size=S, color=red
name=3-wolf shirt, size=L, color=blue
name=frog shirt, size=M, color=white
name=frog shirt, size=S, color=red
{noformat}
Now, if user does a search for "color=red"... without post-group
faceting (ie what Solr has today), you incorrectly see count=3 for
color=red.
With post-group faceting, you should see count=2 for color=red (which
these collectors will do, correctly, I think?), but you should also
see count=2 for size=S, which I think these collectors will fail to
do? (Ie, because they only retain the top doc per group...?).
> Post grouping faceting
> ----------------------
>
> Key: LUCENE-3097
> URL: https://issues.apache.org/jira/browse/LUCENE-3097
> Project: Lucene - Java
> Issue Type: New Feature
> Components: modules/grouping
> Reporter: Martijn van Groningen
> Assignee: Martijn van Groningen
> Priority: Minor
> Fix For: 3.2, 4.0
>
> Attachments: LUCENE-3097.patch
>
>
> This issues focuses on implementing post grouping faceting.
> * How to handle multivalued fields. What field value to show with the facet.
> * Where the facet counts should be based on
> ** Facet counts can be based on the normal documents. Ungrouped counts.
> ** Facet counts can be based on the groups. Grouped counts.
> ** Facet counts can be based on the combination of group value and facet
> value. Matrix counts.
> And properly more implementation options.
> The first two methods are implemented in the SOLR-236 patch. For the first
> option it calculates a DocSet based on the individual documents from the
> query result. For the second option it calculates a DocSet for all the most
> relevant documents of a group. Once the DocSet is computed the FacetComponent
> and StatsComponent use one the DocSet to create facets and statistics.
> This last one is a bit more complex. I think it is best explained with an
> example. Lets say we search on travel offers:
> |||hotel||departure_airport||duration||
> |Hotel a|AMS|5
> |Hotel a|DUS|10
> |Hotel b|AMS|5
> |Hotel b|AMS|10
> If we group by hotel and have a facet for airport. Most end users expect
> (according to my experience off course) the following airport facet:
> AMS: 2
> DUS: 1
> The above result can't be achieved by the first two methods. You either get
> counts AMS:3 and DUS:1 or 1 for both airports.
--
This message is automatically generated by JIRA.
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]
