On Thu, Dec 10, 2009 at 12:40 PM, Erick Erickson <erickerick...@gmail.com> wrote:
> Which of these do you think this patch *should* address before committing? > Just the last two? Well... I'd really like pluggability to a different value source, with "FieldUninverter" just being the one we have today, and adding control/extensibilty over how FieldUninverter deals w/ multi-valued fields. And I'd like to see that LUCENE-1231 could be built within that framework (though we don't have to build/finish it today), as just another value source. StringIndex's error checking is simple to fix separately -- I've opened LUCENE-2142 for that. I think allowing multiple values per field, and being able to cut over norms/deleted docs to field cache, are clearly future items (but we should keep them in mind on such a big change to FieldCache, ie, at least don't "preclude" them or make them harder to achieve). The remaining items I think are relatively simple to fix. Basically, I don't see compelling enough gains as the patch currently stands -- it's largely "moving" the FieldCache API from one place to another (I think?). This generates alot of noise, people must migrate to the new API, but then we still have FieldCache's deeper limitations to live with. Fixing these limitations will require improvements to the external API -- that's what I'd like to get fixed, which would be a good justification for the API movement noise. I think especially with the cutover to per-segment searching, the acceptance (?) that an atomic array is OK, we ought to be able to bang out a basic interface for some plugin to provide native arrays. > As many as Christian has energy for <G>? I don't think this should be all Christian -- we should all help out here! This is a big (and long overdue) change. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
