[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063555#comment-13063555
]
Uwe Schindler commented on LUCENE-1768:
---------------------------------------
Vinicius, do you have any plans about backporting the stuff to Lucene 3.x - it
should not be that hard :-)
bq. I am not sure about numeric support, Vinicius changed TermRangeQueryNode
inheritance, which breaks the backwards compatibility. I am not saying the
change is bad, I agree with the new structure, however Vinicius will need to
find another solution before backporting it to 3.x.
I am not sure if this is really a break when you change inheritance. If code
still compiles, its no break, if classes were renamed its more serious. I am
not sure, if implementation classes (and -names) should be covered by the
backwards compatibility. In my opinion, mainly the configuration and interfaces
of the QP must be covered by backwards policy.
As we are now at mid-time, it would be a good idea, to maybe add some extra
syntax support for numerics, like "<" and ">"? We should also add tests/support
for half-open ranges, so syntax like "[* TO 1.0]" should also be supported (I
am not sure, if TermRangeQueryNode supports this, but numerics should do this
in all cases) - the above syntax is also printed out on
NumericRangeQuery.toString(), if one of the bounds is null. The latter could be
easily implemented by checking for "*" as input to the range bounds and map
those special "values" to NULL. Adding support for "<" and ">" (also "<=",
">=") needs knowledge of JavaCC parser language. Vinicius, have you ever worked
with JavaCC, so do you think you will be able to extend the syntax?
> 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: week-7.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]
