> 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)? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
