Hoss, We rely heavily on facet.mincount because once a user has selected a facet, it doesn't make sense for us to show that facet field to him and let him filter again with the same facet. Also, when a facet has only one value, it doesn't make sense to show it to the user, since searching with that facet is just going to give the same result set again. So when facet.missing does not work with facet.mincount, it is a bit of a hassle for us.... Will work on handling it in our program.....Thank you for the clarification
- Rahul On Wed, Jun 5, 2013 at 12:32 AM, Chris Hostetter <hossman_luc...@fucit.org>wrote: > > : that facet value and see all documents. I thought facet.missing=true was > : the answer. > ... > : facquery.setFacetMinCount(1); > > Hmm, yeah -- it looks like facet.missing doesn't take facet.mincount into > consideration. > > I don't remember if that was intentional or not, but as a special case > one-off count it seems like a toss up as to wether it would be more or > less surprising to hide it if it's below the mincount. (it's very similar > to doing one off facet.query for example, and those are always included in > the response and don't consider the facet.mincount either) > > In general, this seems like a low impact thing though, correct? i mean: > the main advantage of facet.mincount is to reduce what could be a very > large amount of useless data from being stream from the server->client, > particularly in the case of using facet.sort where you really need the > consraints eliminated server side in order to get the sort=limit applied > correctly. > > but with the facet.missing value, it's just a single value per field that > can easily be ignored by the client if it's not desired because of the > mincount. or to put it another way: the amount of work needed to ignor > this on the client, is less then the amount of work to make it > configurable to ignore it on the server. > > > -Hoss >
