: > query would be too expensive -- instead we have strucured metadata that : > drives the logic: only compute the constraint counts for this subset of : > manufactures where looking at teh Desktops category, only look at teh : > Operating System facet when in these categories, etc... rules like these : > need to be defined based on your user experience, and it can be easy to : > build them using the metadata in your index -- but they really : > need to be precomputed, not calculated on the fly every time. : : Sounds interesting, Could you please provide an example of how would one : go about doing a precomuted qurery?
it's domain specific ... we know certain manufactures only make products in certain categories, so we only check the counts for those manufacturers when we are seraching in those categories. : > For something like a LIbrary system, where you might want to facet on : > Author, but you have way to many to be practical, a system that either : > required a category to be picked first (allowing you to constrain the list : > of authors you need to worry about) or precomputed the top 1000 authors : > for displaying initially (when the user hasn't provided any other : > constraints) are examples of the types of things a RequestHandler Solr : > Plugin might do -- but the logic involved would probably be domain : > specific. : : Specifically here without getting any user constrains? how would one do this.. I : thought facets needs to have user constraints? your base query can be anything, even a query that matches on all documents -- but that's a minor technical issue, my point is about hte user experience: you can precompute popular authors to offer the user before they specify any search criteria, or to compute facet counts for when the users given you a simple search phrase, but iterating over every possible author isn't feasible until some other constraint has been provided that reduces the number of authors you have to deal with (like telling you the first initial of hte author) -Hoss
