Unfortunately this won't give you group.facet results:
q=whatever
fq={!collapse tag=collapse}blah
facet.field={!ex=collapse}my_facet_field
This will give you the expanded facet counts as it removes the collapse
filter.
A good explanation of group.facets is here:
http://blog.trifork.com/2012/04/10/faceting-result-grouping/
Joel Bernstein
http://joelsolr.blogspot.com/
On Fri, Jun 19, 2015 at 7:11 AM, Upayavira <u...@odoko.co.uk> wrote:
> On Fri, Jun 19, 2015, at 06:20 AM, Derek Poh wrote:
> > Hi
> >
> > I read about "collapsingQParser returns the facet count the same as
> > group.truncate=true" and has this issue with the facet count and the
> > after filter facet count notthe same.
> > Using group.facetdoes not has this issue but it's performance is very
> > badcompared to collapsingQParser.
> >
> > I trying to understand why collapsingQParser behave this way and will
> > need to explain to management.
> >
> > Can someone explain how collapsingQParser calculatethefacet
> > countscompated to group.facet?
>
> I'm not familiar with group.facet. But to compare traditional grouping
> to the collapsingQParser - in traditional grouping, all matching
> documents remain in the result set, but they are grouped for output
> purposes. However, the collapsingQParser is actually a query filter. It
> will reduce the number of matching results. Any faceting that happens
> will happen on the filtered results.
>
> I wonder if you can use this syntax to achieve faceting alongside
> collapsing:
>
> q=whatever
> fq={!collapse tag=collapse}blah
> facet.field={!ex=collapse}my_facet_field
>
> This way, you get the benefits of the CollapsingQParserPlugin, with full
> faceting on the uncollapsed resultset.
>
> I've no idea how this would perform, but I'd expect it to be better than
> the grouping option.
>
> Upayavira
>
