[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743334#action_12743334
]
Luis Alves edited comment on LUCENE-1768 at 8/14/09 11:16 AM:
--------------------------------------------------------------
{quote}
I would propose to absorb the RangeTools/Utils and DateTools/Utils (ehat is the
correct name???) in one configuration class
{quote}
+1
{quote}
I am not sure how to do this with the new parser. I think of the same like the
MTQRewriteMethod (final static singletons in MTQ that do the rewrite and can be
passed as parameter).
{quote}
I think we probably should have TermRangeQueryNode a NumericQueryNode and 2
builders classes that match that, change ParametricRangeQueryNodeProcessor to
do the dirty work and create the new TermRangeQueryNode and NumericQueryNode in
the correct places, based on the a map with [field name,RangeTools.TYPE] or
something similar.
The builders should simple and just convert each type to the correct Lucene
Object.
- we should rename RangeQueryNode to TermRangeQueryNode (to match lucene name)
- create the new NumericQueryNode that extends from TermRangeQueryNode
- change the ParametricRangeQueryNodeProcessor to read the configuration passed
by the user and create the correct QueryNode objects.
- create a new NumericQueryNodeBuilder add it to the StandardQueryTreeBuilder
mapping.
I hope this helps
was (Author: lafa):
<quote>
I would propose to absorb the RangeTools/Utils and DateTools/Utils (ehat is the
correct name???) in one configuration class
<quote>
+1
<quote>
I am not sure how to do this with the new parser. I think of the same like the
MTQRewriteMethod (final static singletons in MTQ that do the rewrite and can be
passed as parameter).
<quote>
I think we probably should have TermRangeQueryNode a NumericQueryNode and 2
builders classes that match that, change ParametricRangeQueryNodeProcessor to
do the dirty work and create the new TermRangeQueryNode and NumericQueryNode in
the correct places, based on the a map with [field name,RangeTools.TYPE] or
something similar.
The builders should simple and just convert each type to the correct Lucene
Object.
- we should rename RangeQueryNode to TermRangeQueryNode (to match lucene name)
- create the new NumericQueryNode that extends from TermRangeQueryNode
- change the ParametricRangeQueryNodeProcessor to read the configuration passed
by the user and create the correct QueryNode objects.
- create a new NumericQueryNodeBuilder add it to the StandardQueryTreeBuilder
mapping.
I hope this helps
> 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: [email protected]
For additional commands, e-mail: [email protected]
