[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081776#comment-13081776
]
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. IndexSearcher.search() 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: https://issues.apache.org/jira/browse/LUCENE-1768
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
