Right. - we need a "blocking cache" to avoid more than one thread attempting to generate, but that can be done outside the SolrCache for now. - prob want to expose the statistics collected... (see logging output of new faceting stuff) - might want a way to dynamically add caches.. but for now adding a "magic" facetCache that exists even when not on solrconfig.xml is prob easiest (the current solr caches do not get instantiated if they are not in solrconfig.xml - they are seen as optional).
-Yonik On Tue, Dec 2, 2008 at 6:27 PM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > recent wiki updates have be looking at UnInvertedField for the first time (i > haven't been very good at keeping up with commits the last few months) and > i'm wondering about the use of a "static Cache multiValuedFieldCache" keyed > off of SolrIndexSearcher. > > Lucene-Java is trying to move away from this pattern in FieldCache, and in > Solr we already have a nice and robust cache mechanism on each > SolrIndexSearcher -- that includes the possibility of doing auto-warming via > regenerators -- so why don't we suse that for UnInvertedField? > > suggested changes... > > 1) add a new "special" (as opposed to "user") SolrCache instance named > "facetCache" to SolrIndexSearcher (just like filterCache and > queryResultCache) where the key is a field name and the value is an > UnInvertedField instance. > > 2) I think the way the "special" caches are initialized they eist with > defaults even if they aren't declared in solrconfig.xml, but if i'm wrong we > should consier making facetCache work that way. > > 2) add a regenerator for facetCache (relatively trivial) > > 3) remove all of the static cashing code from UnInvertedField > > thoughts? > > > -Hoss
