lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler (JIRA)" <>
Subject [jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
Date Tue, 09 Aug 2011 17:25:27 GMT


Uwe Schindler commented on LUCENE-1768:

bq. for 3x, do not rename RangeQueryNode to TermRangeQueryNode, just deprecate it and document
it saying it will change name in future (Uwe, can you confirm this is the right procedure
for class renaming?!).

I can confirm this, we do it generally a little bit different, there are two possibilities
(depending on if the user will create instances of this class and pass it to the API or if
the API returns the instance):
- For the first case, you would leave the name as in trunk, but simply create an empty subclass
with the old 3.x name (only copy the ctors) and deprecate this subclass.
- For the second case, create the deprecated class as superclass of the new one (and deprecate
it), copying all code to this deprecated class. The problem here is that deprecation inherits...
To fix, you have to declare all methods and let them call super without deprecation.

I agree with the rest of Adriano's comments.

In general this is a contrib module and contrib modules don't have the strict backwards requirements
like core classes. Because of this I would only provide minimal backwards layers (no sophisticated
ones) and document all changes. Backwards compatibility sometimes get a pain, so we even document
and break backwards in core (sometimes). We list all those breaks in the backwards section.
Backwards breaks that can be fixed by recompilation are very minor and should only be documented
(as drop-in-JAR replacements no longer work), so they are no issue at all.

bq. I see the classic QP only uses version to change the default value for certain instance
attributes between 2.9/3.0 and 3.x versions. I think it's only there because 2.9 and 3.0 were
required to be the same, except removed deprecations. I don't think 4.0 will have the same
requirement, will it?

4.0 breaks backwards completely with no deprecation layers. The core API of Lucene changed
hard (new enum types, new structures, totally new API, change from char[] to byte[],... the
list is very long). We have a MIGRATION.txt that explains all changes.

We only add deprecation layers in 3.x core for cases where very high-level user classes are
affected (e.g. methods, so transition is easy). All other places in
Lucene that are more expert will change as described before.

> NumericRange support for new query parser
> -----------------------------------------
>                 Key: LUCENE-1768
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: core/queryparser
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>              Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
>             Fix For: 4.0
>         Attachments: TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch,
TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, week-7.patch, week-8.patch,
week1.patch, week2.patch, week3.patch, week4.patch, week5-6.patch
> It would be good to specify some type of "schema" for the query parser in future, to
automatically create NumericRangeQuery for different numeric types? It would then be possible
to index a numeric value (double,float,long,int) using NumericField and then the query parser
knows, which type of field this is and so it correctly creates a NumericRangeQuery for strings
like "[1.567..*]" or "(1.787..19.5]".
> There is currently no way to extract if a field is numeric from the index, so the user
will have to configure the FieldConfig objects in the ConfigHandler. But if this is done,
it will not be that difficult to implement the rest.
> The only difference between the current handling of RangeQuery is then the instantiation
of the correct Query type and conversion of the entered numeric values (simple Number.valueOf(...)
cast of the user entered numbers). Evenerything else is identical, NumericRangeQuery also
supports the MTQ rewrite modes (as it is a MTQ).
> Another thing is a change in Date semantics. There are some strange flags in the current
parser that tells it how to handle dates.

This message is automatically generated by JIRA.
For more information on JIRA, see:


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

View raw message