lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Move TrieRange to Core/Module and integration issues
Date Mon, 13 Apr 2009 20:30:29 GMT
On Mon, Apr 13, 2009 at 12:05 PM, Uwe Schindler <> wrote:

> For me it would not be a problem, I would use a FilteredTermEnum and
> subclass it, but would only implement next() and the other abstract methods
> would be dummies (including difference() returning 1.0f). Only the enum and
> the term should have a protected access or a getter in this class.

Seems like this is simplest (relax FilteredTermEnum so that it could
be extended, and then you can subclass it with dummies)?

This sounds like a great step forward overall; it's nice to have all
queries that are based on multiple terms share MultiTermQuery.

Moving things to the proper sub-packages, and renaming, also makes
alot of sense.

Re core or module or contrib, it's still being discussed under
uber-thread "Modularization".

> Something other: How about storing the "type" information in FieldInfos and
> invent a AbstractField subclass for numbers (NumberField) returning the
> TrieTokenStream in tokenSteam()? This could help people to index. When
> searching, query parsers could use the information and construct the right
> queries, sorting would automatically choose the right ValueSource/Parser and
> so on.

I would love to do something along these lines (LUCENE-1597 is also
exploring better typed fields/documents).

Once FieldInfos can properly store the fact that a given field has
NumericType (which'd have options to turn on sorting, range filtering,
etc.), then we could default many things properly without requiring
the app to do "per field" things in N different places.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message