I've noticed that performing a query with facet.mincount=0 and no fq clauses results in a response where only facets with non-zero counts are returned, but adding in an fq clause (caused by a user selecting a non-zero-valued facet value checkbox) actually causes a bunch of 0-count facet values completely unrelated to the query to be returned.
Is adding the fq constraint actually widening the query before facet.mincount gets applied? E.g., say a query with no fq constraint produces the following facet values: ID 1234 (1) 1111 (15) 1010 (30) Title Red (11) Green (15) Blue (32) but when the user selects Blue (32), and I add &fq=Color:Blue, Solr returns the following: ID 1 (0) 2 (0) 3 (0) ... 99 (0) 100 (0) Color Orange (0) Teal (0) Red (0) Green (0) Blue (32) Notice how, before the fq clause is added, none of the 0-count facets are returned, even though facet.mincount = 0, but afterward, a bunch of 0-count facets are returned? The context of my question is trying to solve a problem where the application must display facet values with a count of zero as filtering operations remove them from the result set. That is, if Red (10) was displayed after the initial query, but the user filters on Blue (32), then we must still display Red (0) so the user can select it and widen the query. Initially, we were using mincount=1 and managing the missing facets entirely within the application, but now I'm trying to see if we can use mincount=0 and maybe some other constraints to achieve the same behavior without a lot of custom code in the application. Thanks -- View this message in context: http://lucene.472066.n3.nabble.com/Adding-fq-to-query-with-mincount-0-causes-unexpected-0-count-facet-values-to-be-returned-tp2236105p2236105.html Sent from the Solr - User mailing list archive at Nabble.com.
