lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Payloads and TrieRangeQuery
Date Wed, 10 Jun 2009 21:45:55 GMT
On Wed, Jun 10, 2009 at 5:24 PM, Yonik Seeley<yseeley@gmail.com> wrote:
> On Wed, Jun 10, 2009 at 5:03 PM, Michael McCandless
> <lucene@mikemccandless.com> wrote:
>> On Wed, Jun 10, 2009 at 4:04 PM, Earwin Burrfoot<earwin@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message