With tag and exclude you can get the facets counts for the collapsed set
and expanded set in the same query. But group.facets is a different count
then either of those.
group.facets counts each facet bucket once per group.
Joel Bernstein
Search Engineer at Heliosearch
On Fri, Jun 6, 2014 at 1:53 PM, david.w.smi...@gmail.com <
david.w.smi...@gmail.com> wrote:
> I may be misunderstanding the problem, but if it’s what I think it is, then
> users can work-around this now quite easily by using Solr faceting’s
> ability to exclude a named/tagged filter query:
>
> &q=classIDs:12
> &fl=PrSKU
> &fq={!collapse tag=collapse field=PrSKU}
> &facet=true
> &facet.field={! ex=collapse}at_12_wood_tone
> &fq=at_12_wood_tone:”Light Wood”
>
>
> ~ David Smiley
> Freelance Apache Lucene/Solr Search Consultant/Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Jun 6, 2014 at 1:09 PM, Joel Bernstein <joels...@gmail.com> wrote:
>
> > The CollapsingQParserPlugin should give you the same facet counts as
> > group.truncate.
> >
> > You're using group.facets, which the CollapsingQParserplugin doesn't yet
> > support. I think this would be an excellent feature, so we could make a
> > jira ticket to add this feature.
> >
> > Joel Bernstein
> > Search Engineer at Heliosearch
> >
> >
> > On Fri, Jun 6, 2014 at 1:07 PM, Joel Bernstein <joels...@gmail.com>
> wrote:
> >
> > > Reposting this from jira ticket to users list:
> > >
> > > I'm noticing a very weird bug using the CollapsingQParserPlugin. We
> tried
> > > to use this plugin when we realized that faceting on the groups would
> > take
> > > a ridiculous amount of time. To its credit, it works very quickly,
> > however
> > > the facet counts that it gives are incorrect.
> > >
> > > We have a smallish index of about 200k documents with about with about
> > 50k
> > > distinct groups within it.
> > >
> > > When we use the group implementation
> > > (&group=true&group.field=PrSKU&group.facet=true) which I believe this
> > > attempts to emulate, the facet counts are totally correct.
> > >
> > > When we use the field collapsing implementation, it will show an
> > incorrect
> > > count for the non-filtered query, but when we go to the filtered query,
> > the
> > > facet count corrects itself and matches the document count.
> > >
> > > Here are some SOLR responses:
> > >
> > > solrslave01:8983/index/select?q=classIDs:12&fl=PrSKU&fq=
> > > {!collapse%20field=PrSKU}&facet=true&facet.field=at_12_wood_tone
> > >
> > > The facet field will return
> > >
> > > <int name="Dark Wood">867</int>
> > > <int name="Medium Wood">441</int>
> > > <int name="Light Wood">253</int>
> > >
> > > When I actually apply a filter query like so:
> > >
> > >
> > >
> >
> solrslave01:8983/index/select?q=classIDs:12&fl=PrSKU&fq={!collapse%20field=PrSKU}
> > >
> > >
> > >
> >
> &facet=true&facet.field=at_12_wood_tone&fq=at_12_wood_tone:%22Light%20Wood%22
> > >
> > > I actually pull back 270 results and the facet updates itself with the
> > > correct number at the bottom
> > >
> > > <int name="Light Wood">270</int>
> > > <int name="Dark Wood">68</int>
> > > <int name="Medium Wood">66</int>
> > >
> > > If this were the same number pre and post filter query I would assume
> > that
> > > it was simply my data that was bad, however I've pored over this for
> the
> > > better part of a day and I'm pretty sure it's the plugin. For
> reference,
> > > this field that I'm faceting on is a multiValued field, however I have
> > > noticed the exact same behavior on non multiValued fields (such as
> > price).
> > >
> > > I can provide any other details you might need
> > >
> >
>
