On 1/13/2017 7:36 AM, Sebastian Riemer wrote: > Thanks, that's actually where I come from. But I don't want to exclude values > leading to a count of zero. > > Background to this: A user searched for mediaType "book" which gave him 10 > results. Now some other task/routine whatever changes all those 10 books to > be say 10 ebooks, because the type has been incorrect. The user makes a > refresh, still looking for "book" gets 0 results (which is expected) and > because we rule out facet.fields having count 0, I don't get back the > selected mediaType "book" and thus I cannot select this value in the > select-dropdown-filter for the mediaType. This leads to confusion for the > user, since he has no results, but doesn't see that it's because of he still > has that mediaType-filter set to a value "books" which now actually leads to > 0 results.
Some users are always going to be confused in one way or another when something behaves in a way that's contrary to their expectations. If you plan your interface correctly, you can eliminate the biggest sources of confusion ... but there's an applicable saying here: You can never make things idiot-proof. There's always a better idiot. The facet.mincount parameter is the way to deal with this problem, as Bill Bell already mentioned. One of the reasons that facet.mincount exists is to remove terms that have no documents, but still exist in the index. If the q parameter was an actual query instead of "all docs" and the request didn't have facet.mincount, then the facet for that field would still have thirteen entries, many of which might be zero. Thanks, Shawn
