[ 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: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org