Hi, I agree that facets *with* counts are better than without counts, but disagree that they are worthless without counts (see the Amazon link Tommaso posted earlier on this thread). There is value in providing the information that *some* results will appear when a user selects a facet .
The use cases problematic case for counting the facets I have in mind are when a query returns millions of results. This is problematic when one wants to retrieve the exact size of the result set (taking ACLs into account, obviously). When facets are to be retrieved this will be an even harder problem (meaning when the exact number is to be calculated per facet). As an illustration consider a digital asset management application that displays mime type as facets. A query could return 1 million images and, say, 10 video. Is there a way we could support such scenarios (while still counting results per facet) and have a performant implementation? (I should note that I have not tested how long it takes to retrieve and ACL-check 1 million nodes - maybe my concern is invalid) Best regards Michael On 09 Dec 2014, at 09:57, Thomas Mueller <[email protected]> wrote: > Hi, > >> I would like the counts. > > I agree. I guess this feature doesn't make much sense without the counts. > >> 1, 2, and 4 seem like >> bad ideas > >> 1 undercuts the idea that we'd use lucene/solr to get decent >> performance. > > Sorry I don't understand... This is just about the API to retrieve the > data. It still uses Lucene/Solr (the same as all other options). I'm not > sure if you talk about the performance overhead of converting the facet > data to a string and back? This performance overhead is very very small (I > assume not measurable). > > Regards, > Thomas >
