Re: sorting on aggregate averages

[Chris Hostetter <ho...@fucit.org>]

: I am computing a sorted rank list and returning a slice (for pagination) but
: have to recompute the result for each request, although the actual q
: parameter and fq would be cached but not the sorted list which I could cache
: to reuse on subsequent requests.
: 
: I might have a look at the caching also, any suggestions in this regard.

Take a look at "User/Generic Caches" here...

	http://wiki.apache.org/solr/SolrCaching

Your custom handler/component can use SolrIndexSearcher.getCache to see if 
a cache with a specific name has been defined, if it has you can do the 
normal get/put operations on it. The cache will worry about expulsion of 
items if it's full (the only Impl that comes with Solr is an LRUCache, but 
you could write your own if you want), and SolrCore will worry about 
giving you a new cache instance when a new reader is opened.  If you 
implement a CacheRegenerator (and configure it for this cache) then you 
can put whatever custome code in that you want for autowarming entries in 
the cache based on the keys/values of the old cache (ie: warm all the 
keys, warm the "first" N keys, warm all the keys whose values indicate 
they were expensive to compute, etc....)

(just make sure your custom handler/component can function ok even if the 
cache doesn't exist, or if there are cache misses even when you don't 
expect them -- it is after all just a cache, good code should be able to 
function (slowly) without it if it's turned off.)

-Hoss

Re: sorting on aggregate averages

[Umar Shah <um...@wisdomtap.com>]

Thanks!
I'll have a look at that.



On Wed, Apr 2, 2008 at 6:25 AM, Chris Hostetter <ho...@fucit.org>
wrote:

> : I am computing a sorted rank list and returning a slice (for pagination)
> but
> : have to recompute the result for each request, although the actual q
> : parameter and fq would be cached but not the sorted list which I could
> cache
> : to reuse on subsequent requests.
> :
> : I might have a look at the caching also, any suggestions in this regard.
>
> Take a look at "User/Generic Caches" here...
>
>        http://wiki.apache.org/solr/SolrCaching
>
> Your custom handler/component can use SolrIndexSearcher.getCache to see if
> a cache with a specific name has been defined, if it has you can do the
> normal get/put operations on it. The cache will worry about expulsion of
> items if it's full (the only Impl that comes with Solr is an LRUCache, but
> you could write your own if you want), and SolrCore will worry about
> giving you a new cache instance when a new reader is opened.  If you
> implement a CacheRegenerator (and configure it for this cache) then you
> can put whatever custome code in that you want for autowarming entries in
> the cache based on the keys/values of the old cache (ie: warm all the
> keys, warm the "first" N keys, warm all the keys whose values indicate
> they were expensive to compute, etc....)
>
> (just make sure your custom handler/component can function ok even if the
> cache doesn't exist, or if there are cache misses even when you don't
> expect them -- it is after all just a cache, good code should be able to
> function (slowly) without it if it's turned off.)
>
> -Hoss
>
>