difficult to pass parameters to a custom
>> >> DVProducer (data location, host/port, other DV fields to use as primary
>> >> key lookups, etc)?
>> >>
>> >
>> > its not involved if you implement via FilterAtomicReader. its only
>> > involved
>> key lookups, etc)?
> >>
> >
> > its not involved if you implement via FilterAtomicReader. its only
> > involved for reading things that are actually written into the index.
> >
> > -------------
> >
the index.
> >
> > -------------
> > To unsubscribe, e-mail:
>
> > dev-unsubscribe@.apache
>
> > For additional commands, e-mail:
>
> > dev-help@.apache
>
>
>
>
>
>
actually written into the index.
>
> -
> To unsubscribe, e-mail:
> dev-unsubscribe@.apache
> For additional commands, e-mail:
> dev-help@.apache
-
Author: http://www.packtpub.com/apache-solr-3-e
On Sat, Mar 23, 2013 at 7:25 AM, Alan Woodward 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 already cac
> 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 Fri, Mar 22, 2013 at 6:26 PM, Alan Woodward 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
> another ca
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 ough
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, M
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 command
he
> moment, which means I can't extend 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
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 p
12 matches
Mail list logo
