that's a very good way to do it. You could also use SolrIndexSearcher.numDocs -- it is esentially the same thing, but in the future there may be optimizations that can be done to eliminate the construction of one DocSet (if the other one already exists)
Thank you for the tip -- I will take a look at it.
: general. To that end, my current structure defines: : : - a <facetHandler/> entry in solrconfig.xml, the only current : implementation of which loads a set of Facet definitions from an xml : file. : - each Facet contains an id for lookups and a List of FacetItems (some : statically configured, some constructed dynamically from available : Terms, though not backed by any cache yet.) : - each FacetItem contains a displayName and Query (and associated queryString) I'm not sure i understahnd what exactly the "facetHandler" registration gains you that you couldn't have achieved in a custome requestHandler (without needing to modify the internals/config parrsing and so on) ... your custom request handler could take in a "FacetHandler" class name as an init param, or it could have taken in the XML information directly as deeply nested set of init params. am i missing something else?
No, your are not missing anything; that may be a less intrusive way to do this. I wouldn't be the first time I have out-thought myself :). I started with the concept of a facetHandler, becasue my goal was faceting as a utility different handlers could share, as opposed to the responsibility of a specific requestHandler. This allows: 1) The adding/reusing of faceting to any requestHandler with minimal code. While, as you point out, I could have done this with a custom requestHandler, this approach lets any requestHandler add faceting. I have it currently inside StandardRequestHandler and DisMaxRequestHandler. (Admittedly, these now qualify as custom request handlers, but the code block is simply "if request has faceting params, add the facets requested to the output".) 2) One configuration place for faceting. I have a very mixed content index, which could contain Reviews, Articles, and Products of different categories, each of which could potentially have a separately configured requestHandler to give their specific fields appropriate default weight. I would rather not have to specify (or load) the facet "handling" in every requestHandler definition. 3) Faceting to differ per-request. The request has to be able to specify what facets to put in the output, and this required a change to SolrQueryRequest to add these parameters. (It seemed more appropriate to add them explicitly, rather than grabbing them from the args.) Of these, #1 is probably the only strong reason to have a concept of a facetHandler -- #2 and #3 are a matter of preference. The changes to Solr proper were surprisingly small, which is a testament to your initial structure, but I did have to add elements to SolrQueryRequest and SolrCore. Placing the responsibility for faceting inside a custom requestHandler may restrict its reusability in other handlers, but it would eliminate the need for these changes. Perhaps a more appropriate middle way for me would be to load the "facetHandler" as a user cache, as opposed to its own named item, and acheive sharing across requestHandlers that way. This raises its own set of problems, but it would be far less invasive. Thanks, Greg
