[ 
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740608#action_12740608
 ] 

Michael McCandless commented on LUCENE-1768:
--------------------------------------------

bq. You could still do something similar by simply override 
RangeQueryNodeBuilder.build(QueryNode queryNode), but this is not clean (it is 
kind of a hack).

What's the cleaner way to do this?  EG could I make my own 
ParametricRangeQueryNodeProcessor, subclassing the current one in the 
"standard.processors" package, that overrides postProcessNode to do its own 
conversion?

> 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: QueryParser
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 2.9
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to