hossman wrote: > > > : I want a couple of costly queries to be cached at all times in the > : queryResultCache. (unless I have a new searcher of course) > > first off: you can ensure that certain queries are in the cache, even if > there is a newSearcher, just configure a newSearcher Event Listener that > forcibly warms the queries you care about. > > (this is particularly handy to ensure FieldCache gets populated before any > user queries are processed) > > Second: if i understand correctly, you want a way to put an object in the > cache, and garuntee that it's always in the cache, even if other objects > are more frequetnly used or more recently used? > > that's kind of a weird use case ... can you elaborate a little more on > what exactly your end goal is? > >
Sure. Actually i got the idea of another thread posted by Thomas to which you gave a reply a few days ago: http://www.nabble.com/Result-grouping-options-tf4522284.html#a12900630. I quote the relevant bits below, although I think you remember: hossman wrote: > > : Is it possible to use faceting to not only get the facet count but also > the > : top-n documents for every facet > : directly? If not, how hard would it be to implement this as an > extension? > > not hard ... a custom request handler could subclass > StandardRequestHandler, call super.handleRequest, and then pull the field > faceting info out of the response object, and fetch a DocList for each of > the top N field constraints. > I have about a dozen queries that I want to have permanently cached, each corresponding to a particular navigation page. Each of these pages has up to about 10 top-N lists which are populated as discussed above. These lists are pretty static (updated once a day, together with the index). The above would enable me to populate all the lists on a single page in 1 pass. Correct? Although I haven't tried yet, I can't imagine that this request returns in sub-zero seconds, which is what I want (having a index of about 1M docs with 6000 fields/ doc and about 10 complex facetqueries / request). The navigation-pages are pretty important for, eh well navigation ;-) and although I can rely on frequent access of these pages most of the time, it is not guarenteed (so neither is the caching) hossman wrote: > > the most straightforward approach i can think of would be a new cache > implementation that "permenantly" stores the first N items you put in it. > that in combination with the newSearcher warming i described above should > work. > > : 1. use User/Generic-cache. This would result in seperate coding-path in > : application which I would like to avoid. > : 2. exend LRU-cache, and extend request-handler so that a query can be > : extended with a parameter indicating that it should be cached at all > times. > : However, this seems like a lot of cluttering-up these interfaces, for a > : relatively small change. > > #1 wouldn't really accomplish what you want without #2 as well. > > > > -Hoss > > > regarding #1. Wouldn't making a user-cache for the sole-purpose of storing these queries be enough? I could then reference this user-cache by name, and extract the correct queryresult. (at least that's how I read the documentation, I have no previous experience with the user-cache mechanism). In that case I don't need #2 right? Or is this for another reason not a good way to handle things? //Geert-Jan -- View this message in context: http://www.nabble.com/how-to-make-sure-a-particular-query-is-ALWAYS-cached-tf4566711.html#a13048285 Sent from the Solr - User mailing list archive at Nabble.com.
