On Thu, Feb 23, 2012 at 1:32 PM, Ryan McKinley <[email protected]> wrote: > In LUCENE-3360, there is discussion that DocValues could be used to > replace the existing FieldCache. This seems like is a great > direction, but I am not sure how people see this getting implemented. > > Is the suggestion to add something like: > DocValues fieldCache(String field); > to AtomicReader?
No, my suggestion is not to add anything to indexreader at all. IndexReader is decoupled from FieldCache, I think we should keep it that way. You can already sort, group, etc on docvalues fields... so I'm arguing that users should say up front which fields they are going to sort/group on so we can actually be an index and compute this stuff at indexing time, rather than uninverting at search time (and do this stuff more effectively with ideas like LUCENE-3729). Thus this "compute/uninvert on the fly" fieldcache could be moved somewhere else. Grouping etc could work solely on a docvalues api and maybe they have a special ctor to take a SortedBytes impl (and fieldcache implements the docvalues api or some other backwards mechanism). This would remove the redundant implementations (both fieldcache and DV implementations) in stuff like grouping, join, sort, etc Sure its a change, but so is making IndexReader read-only and other things we have done. -- lucidimagination.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
