On Wed, Jun 10, 2009 at 5:24 PM, Yonik Seeley<ysee...@gmail.com> wrote: > On Wed, Jun 10, 2009 at 5:03 PM, Michael McCandless > <luc...@mikemccandless.com> wrote: >> On Wed, Jun 10, 2009 at 4:04 PM, Earwin Burrfoot<ear...@gmail.com> wrote: >> * Was the field even indexed w/ Trie, or indexed as "simple text"? > > Why the special treatment for Trie?
So that at search time things default properly. Ie, RangeFilter would rewrite to the right impl (if we made a single RangeFilter that handled both term & numeric ranges), and sorting could pick the right parser. Ie, ideally one simply adds NumericField to their Document, indexes it, and then range filtering & sorting "just work". It's confusing now the separate steps you must go through to use trie, because Lucene doesn't remember that you indexed with trie. But, I realize this is a stretch... eg we'd have to fix rewrite to be per-segment, which certainly seems spooky. A top-level schema would definitely be cleaner. >> * We have a bug (or an important improvement) in how Trie encodes >> terms that we need to fix. This one is not easy to handle, since >> such a change could alter the term order, and merging segments >> then becomes problematic. Not sure how to handle that. Yonik, >> has Solr ever had to make a change to NumberUtils? > > Nope. If we needed to, we would make a new field type so that > existing schemas/indexes would continue to work. OK seems like Lucene should take the same approach. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
