lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul R <>
Subject Re: facet.missing=true returns null records with zero count also
Date Wed, 05 Jun 2013 17:17:10 GMT
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

> : 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message