[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082741#comment-13082741 ]
Adriano Crestani commented on LUCENE-1768: ------------------------------------------ {quote} I just don't understand why ParametricQueryNode hold this CompareOperator value, I think this should be part of the ParametricRangeQueryNode and ParametricQueryNode should only be a simple value (FieldQueryNode). Any suggestions here? {quote} That's a looong story. And you are right, they are not compatible (my fault) and CompareOperator does not make much sense. Today, if you want, you can set a ParametricRangeQueryNode with CompareOperator.LE set in the two bounds :S. Lets take the opportunity and try to redesign it. I also agree that ParametricRangeQueryNode could only have FieldQueryNode as its bounds, so I think we can get rid of ParametricQueryNode (for 4.0). For now, I will suggest the following change: - keep using ParametricQueryNode in ParametricRangeQueryNode - deprecate ParametricQueryNode - make ParametricRangeQueryNode implement that RangeQueryNode interface I mentioned on my last comment. This interface will have isLowerInclusive, isUpperInclusive, setUpperInclusive and setLowerInclusive. For the template parameter, ParametricRangeQueryNode should use FieldQueryNode. - Make sure whenever the user sets lowerInclusive and upperInclusive we replicate that to the ParametricQueryNode (upper and lower bounds) setting the equivalent CompareOperator. I think this way we can get rid of ParametricQueryNode in future. I don't know the implications of these changes, since I haven't tried it. So let me know if you find any new conflict. > 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org