Re: understanding collapsingQParser with facet vs group.facet

2015-06-22 Thread Joel Bernstein
The group head is the document from each group that was selected during the
collapse. Only the group heads remain in the result set following the
collapse. It looks like in the example above you have the basic idea
correct.

Joel Bernstein
http://joelsolr.blogspot.com/

On Sat, Jun 20, 2015 at 12:40 AM, Derek Poh d...@globalsources.com wrote:

 Hi Joel

 By group heads, is it referring to the document thatis use to represent
 each group in the main result section?

 Eg. Using the below 3 documentsandwe collapse on field supplier_id

 supplier_id:S1
 product_id:P1

 supplier_id:S2
 product_id:P2

 supplier_id:S2
 product_id:P3

 With collapse on supplier_id, the result in the main sectionis as follows,

 supplier_id:S1
 product_id:P1

 supplier_id:S2
 product_id:P3

 The group head of supplier_id:S1 is P1and supplier_id:S2 will be P3?

 Facets (and even sort) are calculated on P1 and P3?

 -Derek


 On 6/19/2015 7:05 PM, Joel Bernstein wrote:

 The CollapsingQParserPlugin currently doesn't calculate facets at all. It
 simply collapses the document set. The facets are then calculated only on
 the group heads.

 Grouping has special faceting code built into it that supports the
 group.facet functionality.

 Joel Bernstein
 http://joelsolr.blogspot.com/

 On Fri, Jun 19, 2015 at 6:20 AM, Derek Poh d...@globalsources.com
 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?

 Thank you,
 Derek







Re: understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Derek Poh

Hi Upayavira

Thank you for your explanation onthe difference between traditional 
grouping and collapsingQParser. I understand more now.


On 6/19/2015 7:11 PM, Upayavira 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






Re: understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Derek Poh

Hi Joel

By group heads, is it referring to the document thatis use to represent 
each group in the main result section?


Eg. Using the below 3 documentsandwe collapse on field supplier_id

supplier_id:S1
product_id:P1

supplier_id:S2
product_id:P2

supplier_id:S2
product_id:P3

With collapse on supplier_id, the result in the main sectionis as follows,

supplier_id:S1
product_id:P1

supplier_id:S2
product_id:P3

The group head of supplier_id:S1 is P1and supplier_id:S2 will be P3?

Facets (and even sort) are calculated on P1 and P3?

-Derek

On 6/19/2015 7:05 PM, Joel Bernstein wrote:

The CollapsingQParserPlugin currently doesn't calculate facets at all. It
simply collapses the document set. The facets are then calculated only on
the group heads.

Grouping has special faceting code built into it that supports the
group.facet functionality.

Joel Bernstein
http://joelsolr.blogspot.com/

On Fri, Jun 19, 2015 at 6:20 AM, Derek Poh d...@globalsources.com 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?

Thank you,
Derek







understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Derek Poh

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?


Thank you,
Derek




Re: understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Upayavira
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


Re: understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Joel Bernstein
The CollapsingQParserPlugin currently doesn't calculate facets at all. It
simply collapses the document set. The facets are then calculated only on
the group heads.

Grouping has special faceting code built into it that supports the
group.facet functionality.

Joel Bernstein
http://joelsolr.blogspot.com/

On Fri, Jun 19, 2015 at 6:20 AM, Derek Poh d...@globalsources.com 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?

 Thank you,
 Derek





Re: understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Joel Bernstein
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



Re: understanding collapsingQParser with facet vs group.facet

2015-06-19 Thread Joel Bernstein
The AnalyticsQuery can be used to implement custom faceting modules. This
would allow you to calculate facets counts in an algorithm similar to
group.facets before the result set is collapsed. If you are in distributed
mode you will also need to implement a merge strategy:

http://heliosearch.org/solrs-new-analyticsquery-api/
http://heliosearch.org/solrs-mergestrategy/

Joel Bernstein
http://joelsolr.blogspot.com/

On Fri, Jun 19, 2015 at 7:28 AM, Joel Bernstein joels...@gmail.com wrote:

 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