/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl-tp4050537p4051217.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com
://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl-tp4050537p4051217.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl-tp4050537p4051217.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com
:
dev-unsubscribe@.apache
For additional commands, e-mail:
dev-help@.apache
-
Author:
http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl-tp4050537p4051217.html
Sent
I think instead FieldCache should actually be completely package
private and hidden behind a UninvertingFilterReader and accessible via
the existing AtomicReader docValues methods.
Aha, right, because SegmentCoreReaders already caches XXXDocValues instances
(without using WeakReferences or
On Sat, Mar 23, 2013 at 7:25 AM, Alan Woodward a...@flax.co.uk wrote:
I think instead FieldCache should actually be completely package
private and hidden behind a UninvertingFilterReader and accessible via
the existing AtomicReader docValues methods.
Aha, right, because SegmentCoreReaders
I'm looking at exposing data held externally to an index via a ValueSource, and
it would be nice to reuse the machinery in FieldCacheImpl to cache the data
per-segment. However, it's package-private at the moment, which means I can't
extend it nicely. Is there a reason for this? Or should I
it nicely. Is there a reason for this?
Or should I put up a JIRA to make it public?
Alan Woodward
www.flax.co.uk
-
Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
--
View this message in context:
http://lucene.472066.n3.nabble.com/Opening-up-FieldCacheImpl
The ability to cache stuff w/o resorting to weak references would be even nicer!
Caches right on the segment readers?
-Yonik
http://lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional
Note that what fieldcache does is not special, it just has a map and
calls the public SegmentReader.addCoreClosedListener method so that it
gets notifications when something is no longer needed.
I'm not sure we should make fieldcacheimpl public if thats the real
logic you want to reuse.
On Fri,
Actually this would be really nice, wouldn't it. Add a getFieldCache(String
field) method to AtomicReader. You'd have to be able to determine what to
return depending on the field though - uninverted field, or docvalues, or
another cached source.
FieldCache and DocValues seem like they
On Fri, Mar 22, 2013 at 6:26 PM, Alan Woodward a...@flax.co.uk wrote:
Actually this would be really nice, wouldn't it. Add a getFieldCache(String
field) method to AtomicReader. You'd have to be able to determine what to
return depending on the field though - uninverted field, or docvalues, or
12 matches
Mail list logo