On Sat, Mar 23, 2013 at 7:25 AM, Alan Woodward <[email protected]> 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 caches XXXDocValues instances > (without using WeakReferences or anything like that). > > I should explain my motivation here. I want to store various scoring factors > externally to Lucene, but make them available via a ValueSource to > CustomScoreQueries - essentially a generalisation of FileFloatSource to any > external data source. FFS already has a bunch of code copied from > FieldCache, which was why my first thought was to open it up a bit and extend > it, rather than copy and paste again. > > But it sounds as though a nicer way of doing this would be to create a new > DocValuesProducer that talks to the external data source, and then access it > through the AR docValues methods. Does that sound plausible? Is SPI going > to make it 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 for reading things that are actually written into the index. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
