: After thinking over your comments, I removed the facetHandler : completely, instead loading the Facets into a plain user cache, and : put the output work in a utils class similar to SolrPluginUtils. It : complicates the Term caching for me slightly, but it allows me to add : a "FacetUtils.doStandardFaceting(req, query, results);" type of call : to any requestHandler without any changes to Solr internals. Thank : you for pointing me in that general direction.
Don't let me discourage you from having a "FacetHandler" interface that supports generic faceting functionality using different rules (ie: faceting based on a config file, faceting based on the top terms from a list of fields, facets based on other facets, etc) i just wasn't sure what benefit ou got from having a <facetHandler> declaration in the solrconfig seperate from the requestHandlers -- as you said, request handlers need to know that they are doing faceting, so it might as well be an explicit part of their configuration. With something like responseWriter it makes sense for orthoginal configuration, because you should be able to use any response writer with an request handler -- but not all request handlers make sense with faceting (not to mention you might have one handler that wants to use faceting in two or more completely different ways on different DocSets) But it sounds like you are on a good track now with a generic utility class that can be used by any request handler as it sees fit -- a pluggable machanism for detemring how the facets are determined seems cool. : - Since valueDocSet.intersectionSize(otherSet) compares the actual : result set. the requestHandler needs to get a full (or at least : larger) set before limiting it by req.getStart() and req.getLimit(), : or you only calculate the facets against that one page. Then, after : you calculate the facets, you can use subset() to restrict the range : for output. : : - searcher.numDocs(resultQuery, facetQuery) does not require any : subset steps, but, since it uses the Query, not the end DocList, it : does not know about any filter queries applied to the request. The : facet intersection will therefore be calculated against documents that : are not returned in the base results NamedList. take a look at SolrIndexSearcher.getDocListAndSet -- it efficiently gets you both the "paginated" DocList to display for this request and the full DocSet for doing faceting at the same time, and it can also take in a list of Filtering queries. Then you can pass in the resulting DocSet as the second arg to numDocs. -Hoss
