[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13100792#comment-13100792 ] Vinicius Barros commented on LUCENE-1768: - Hi Uwe, That's it. No, I don't have any other changes in my workspace. It was nice working with you, thanks! 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: 3.4, 4.0 Attachments: TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, TestNumericQueryParser-fix.patch, week-14.patch, week-7.patch, week-8.patch, week1.patch, week11-13_for_lucene_3x.patch, week11-13_for_lucene_3x.patch, week15_for_lucene_3x.patch, week15_for_trunk.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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week15_for_lucene_3x.patch week15_for_trunk.patch Sorry Uwe, college is taking my time again. Here are the latest changes, for trunk and 3x. Tests are passing for both. 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-14.patch, week-7.patch, week-8.patch, week1.patch, week11-13_for_lucene_3x.patch, week11-13_for_lucene_3x.patch, week15_for_lucene_3x.patch, week15_for_trunk.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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week-14.patch I have changed again trunk to reflect the latest changes on 3x. I also realized that ParametricRangeQueryNode and TermRangeQueryNode are basically the same, so I decided to removed ParametricRangeQueryNode and only use TermRangeQueryNode. Everything seems to be working fine. Let me know if I should not have done that for any reason. I have some few changes on 3x to submit yet, but I was wondering: is it necessary to deprecate a class in 3x if it's ONLY going to be removed in 4.0? Not sure if I understand how these things work yet. 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-14.patch, week-7.patch, week-8.patch, week1.patch, week11-13_for_lucene_3x.patch, week11-13_for_lucene_3x.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088312#comment-13088312 ] Vinicius Barros commented on LUCENE-1768: - Thanks Adriano, your summary looks better! To trunk behavior changes, I would add that StandardSyntaxParser no longer outputs ParametricRangeQueryNodes for range queries, instead, it outputs TermRangeQueryNodes. 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-14.patch, week-7.patch, week-8.patch, week1.patch, week11-13_for_lucene_3x.patch, week11-13_for_lucene_3x.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087515#comment-13087515 ] Vinicius Barros commented on LUCENE-1768: - Thanks for committing the patch Uwe. I tried to summarize everything I have changed so far for this JIRA. I hope this helps: - new query node interfaces: FieldValuePairQueryNode, ValueQueryNode - FieldQueryNode now implements FieldValuePairQueryNode - two new public methods added to StandardQueryParser: setNumericConfigMap and getNumericConfigMap - new query builders: DummyQueryNodeBuilder, NumericRangeQueryNodeBuilder, TermRangeQueryNodeBuilder - removed builders (trunk only): RangeQueryNodeBuilder - changes to StandardQueryTreeBuilder configuration: it now uses DummyQueryNodeBuilder for NumericQueryNodes and uses NumericRangeQueryNodeBuilder for NumericRangeQueryNodes - changes to StandardQueryTreeBuilder configuration (trunk only): removed builder for RangeQueryNodes, as this class was removed in trunk - added NumberDateFormat, that helps to parse/format dates into number and index it as numeric - added NumericConfig, used to set the numeric configuration of a certain field in the query parser. It contains information about its numeric type, how to parse/format from/to string and its precision step. - added NumericFieldConfigListener that sets the corresponding NumericConfig object to the FieldConfig object - added NUMERIC_CONFIG and NUMERIC_CONFIG_MAP constants to StandardQueryConfigHandler, used to set numeric configuration to StandardQueryConfigHandler - added AbstractRangeQueryNode that is the common parent of all currently available RangeQueryNodes - added RangeQueryNode interface, that should be implemented by all range query nodes, such as NumericRangeQueryNode and TermRangeQueryNode - added NumericQueryNode, which is equivalent to FieldQueryNode, but holds a Number instead of String - added NumericRangeQueryNode, which is equivalent to TermRangeQueryNode, but holds NumericQueryNodes instead of ParametricQueryNodes (3x)/FieldQueryNodes(trunk) - added NumericRangeQueryNodeProcessor, that processes RangeQueryNodes and convert them to NumericRangeQueryNodes when its field is configured as numeric - added NumericQueryNodeProcessor, which converts FieldQueryNodes into NumericRangeQueryNodes (lower bound == upper bound) when the field is configured as numeric - (trunk only) ParametricRangeQueryNodeProcessor now creates TermRangeQueryNode instead of RangeQueryNode from ParametricRangeQueryNode - changed StandardQueryNodeProcessorPipeline configuration: NumericQueryNodeProcessor followed by NumericRangeQueryNodeProcessor are executed right after LowercaseExpandedTermsQueryNodeProcessor - (3x only) deprecated RangeQueryNode, TermRangeQueryNode should be used instead - (3x only) deprecated ParametricQueryNode, FieldQueryNode should be used instead and the compare operators should be set using RangeQueryNode.setLowerBoundInclusive and RangeQueryNode.setUpperBoundInclusive methods 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, week11-13_for_lucene_3x.patch, week11-13_for_lucene_3x.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087516#comment-13087516 ] Vinicius Barros commented on LUCENE-1768: - Right now I am reviewing the API changes I did in 3x and trying to replicate it back to trunk (removing deprecated classes, etc). I should have a new patch soon. 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, week11-13_for_lucene_3x.patch, week11-13_for_lucene_3x.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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week11-13_for_lucene_3x.patch This patches backports the numeric support to 3x. Uwe and Adriano, please, review it and let me know if the backports looks OK. Thanks! 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, week11-13_for_lucene_3x.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13082128#comment-13082128 ] Vinicius Barros commented on LUCENE-1768: - Hi Uwe and Adriano, Thanks for the comments. I have been trying to follow Adriano's instructions to avoid major changes to API and behavior. However, ParametricRangeQueryNode and AbstractRangeQueryNode do not share the same methods (as Adriano said above). ParametricRangeQueryNode has lower and upper bound, which are ParametricQueryNodes, and these last ones hold the inclusive/exclusive information (they use CompareOperator for that). AbtractRangeQueryNode have lower and upper bounds (these ones defined by the template, so it could be a ParametricQueryNode, which is compatible with ParametricRangeQueryNode), however it holds the inclusive/exclusive information differently, through isLowerInclusive and isUpperInclusive methods. 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? 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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13080357#comment-13080357 ] Vinicius Barros commented on LUCENE-1768: - Sorry, I have been in silence for so long time, trying to get some results, but many doubts showed up, I need to guidance here. First, I started working on implementing =, =, , and = operator for standard query parser. Then I later realized someone had submitted a patch for that already and I stopped working on it. Then I decided to implement support for date resolutions for numeric queries in query parser. I started by changing NumberDateFormat to receive a resolution parameter (DAY, SECONDS, MINUTES, etc) and this new parameter is taken into account when doing the date conversion. For that, I added a new method to do the date rounding that takes TimeZone into account, since the current round methods in DateTools do not support timezone. I was able to make it work up to this part. After that, I started to work on date compression, as you suggested before Uwe. For example, if the user wants a DAY resolution, NumberDateFormat should only return the number of days for the given date since 1970, not the miliseconds. For SECOND resolution, it's easy, just divide the miliseconds by 1000. For minutes the same, divide the miliseconds by 1000 * 60 and so on. However, when I got to month, I have no easy way to compress the miliseconds, I mean, no easy way to truncate the days and only get the month count since 1970. The only good solution I found was to get the number of years since 1970 and multiply by 12 plus the current month number. I am still wondering if we can always assume that dividing the miliseconds by 1000 (sec), 60 (minute), 60 (hour) and 24 (day) will actually be precise. What about the leap second? Not sure if the miliseconds - (defined_resolution) and (defined_resolution) - miliseconds will always be correct. Maybe I am missing something or overcomplicating. 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
[jira] [Commented] (LUCENE-3338) Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges
[ https://issues.apache.org/jira/browse/LUCENE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13071501#comment-13071501 ] Vinicius Barros commented on LUCENE-3338: - Hi Uwe, I used javacc-4.1. When I ran ant javacc by the first time and it didn't find it, it told me I should use javacc-4.1, so I installed it. Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges -- Key: LUCENE-3338 URL: https://issues.apache.org/jira/browse/LUCENE-3338 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 3.3 Reporter: Vinicius Barros Fix For: 4.0 Attachments: week9-merged-nosurround.patch, week9-merged.patch, week9.patch Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges. These two problems were found while developing LUCENE-1768. -- 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
[jira] [Updated] (LUCENE-3338) Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges
[ https://issues.apache.org/jira/browse/LUCENE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-3338: Attachment: week9-merged-nosurround_with_failing_junit.patch hi Uwe, I changed the patch to make the junit fail and you see the problem with [x TO x} matching nothing. Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges -- Key: LUCENE-3338 URL: https://issues.apache.org/jira/browse/LUCENE-3338 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 3.3 Reporter: Vinicius Barros Fix For: 4.0 Attachments: week9-merged-nosurround.patch, week9-merged-nosurround_with_failing_junit.patch, week9-merged.patch, week9.patch Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges. These two problems were found while developing LUCENE-1768. -- 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
[jira] [Created] (LUCENE-3338) Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges
Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges -- Key: LUCENE-3338 URL: https://issues.apache.org/jira/browse/LUCENE-3338 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 3.3 Reporter: Vinicius Barros Fix For: 4.0 Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges. These two problems were found while developing LUCENE-1768. -- 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
[jira] [Updated] (LUCENE-3338) Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges
[ https://issues.apache.org/jira/browse/LUCENE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-3338: Attachment: week9.patch The patch available includes week-8.patch attached to LUCENE-1768. Open ranges now work on flexible standard query parser. Mixed include and exclude bounds are now supported on flexible standard query parser. Added junits to cover both problems. Added the same junit tests to classic query parser. I found something while creating junits for the mixed include and exclude bounds. [1 TO } will always return nothing. It seems the exclusive operator there will take precedence over the inclusive operator. I double checked, and the NumericRangeQuery is correct, so I suppose this is the expected behavour of NumericRangeQuery. Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges -- Key: LUCENE-3338 URL: https://issues.apache.org/jira/browse/LUCENE-3338 Project: Lucene - Java Issue Type: Bug Components: modules/queryparser Affects Versions: 3.3 Reporter: Vinicius Barros Fix For: 4.0 Attachments: week9.patch Flexible query parser does not support open ranges and range queries with mixed inclusive and exclusive ranges. These two problems were found while developing LUCENE-1768. -- 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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week-8.patch This patch includes javadocs for the changes I did so far. I am working right now on fixing open range bug on flexible standard query parser. 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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065640#comment-13065640 ] Vinicius Barros commented on LUCENE-1768: - Hi Uwe, Thanks for fixing the junit, I think changing the order of those processors is OK, mainly if Numeric processors do no require lowercasing. 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, 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064100#comment-13064100 ] Vinicius Barros commented on LUCENE-1768: - Hi Robert, Thanks for fixing the problems. About the tests failing, do you know how I can reproduce it? When I was testing, whenever I hit a failure, ant would give me some seed values so I could set in the properties when re-running the tests. Do you have the same values? 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064222#comment-13064222 ] Vinicius Barros commented on LUCENE-1768: - Hi Robert, I updated my code to latest revision and I don't get any junit failure, I ran ant test -Dtestcase=TestNumericQueryParser -Dtestmethod=testSimpleNumericQuery -Dtests.seed=941414100019268099:-3819525649270784880 -Dtests.multiplier=3 in contrib/queryparser and junit on eclipse with -Dtestcase=TestNumericQueryParser -Dtestmethod=testSimpleNumericQuery -Dtests.seed=941414100019268099:-3819525649270784880 -Dtests.multiplier=3 None of them failed. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13063607#comment-13063607 ] Vinicius Barros commented on LUCENE-1768: - Thanks for committing the patch Uwe! I will review the code again looking for switch without default case and fix it. I never did anything with javacc, I just quickly looked at the code, does not seem complicated, however, I have no idea how complex is to run javacc and regenerate the java files. Does lucene ant script do that automaticaly? I can try to fix open range queries on contrib query parser, add =-like operators or backport numeric support to 3.x. Just let me know the priorities and I will work on it. My suggestion is that the bug on open range queries is the most critical now, so I could start working on that. Your call Uwe. 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week-7.patch This patch includes the fix for the new config api and all changes suggested by Uwe. Uwe, you should be able to commit it now, I checked out the trunk and applied the patch myself and everything is working fine. 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: Adriano Crestani 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060176#comment-13060176 ] Vinicius Barros commented on LUCENE-1768: - Hi Uwe, I talked to Phillipe about the new API, it does not look complicated. I will try to do the change and submit a new patch by the end of this week, then we can finally have something checked in \o/ Next things do to then: -fix config -write javadocs -write wiki/tutorial explaining how to use query parser with numeric fields Something else you have in mind Uwe that we can add to the above list? Maybe fix the range query in contrib queryparser which I mentioned in my past comments above. (Have you verified the bug Adriano?) 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: 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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060192#comment-13060192
]
Vinicius Barros commented on LUCENE-1768:
-
Hi Uwe,
I think the bug in Contrib QP is there because it's also a bug in Lucene's
Core QP (the default impl just emulates core's QP). But in my opinion, it
should have separate include/exclude for both limits, so a query like {1 TO
2] should behave as expected.
I think the same way, no idea why it's not supporting {1 TO 2]. I can try to
fix it, but not sure how long it will take, haven't looked at the code yet.
Anyway, it shouldn't be that hard, since core QueryParser is already working
the way we expect, we need somehow to copy the same behavour to contrib
queryparser.
in NumericRangeQueryNodeBuilder, i would use switch statement on the
NumericField.DataType and throw a UnsupportedEx if an unknown type is hit. I
want to do this, because there is already an issue open to extend
NumericField and NumericRangeQuery by BYTE and SHORT. If we add those types,
the code gets unpredictable. With a switch statement and a exception in the
defalt clause, it fails predicatable. You should also add similar default
statement throwing exceptions in all switch statements on this enum type (in
general it is good code style to do this).
Agreed! I will do the change.
The current code always handles Date as Long (like Solr does). I am not
sure, if this would always be the best idea (see e.g. Lucene In Action
book). Maybe we should add a possibility to override the conversion Date -
Number at a central place to customize? One of the reasons to not support
direkt DateRangeQueries was to make the representation of Dates as Numbers
open to the user.
Do you mean that Date could return some other type other than LONG? Like INT?!
I could add a new parameter to NumberDateFormat that will receive
NumeridField.DataType, this way the code could parse the date to the expected
number type.
Method NumericField.DataType getNumericDataType(Number number): I would
use instanceOf checks (as all Number subclasses are final, this is fine and
correct). They should be faster than this reflection code.
I will change that as well.
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: Adriano Crestani
Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 4.0
Attachments: 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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060196#comment-13060196 ] Vinicius Barros commented on LUCENE-1768: - In general, the formatting of a Date to a Number should be possible to customize (e.g. if you only want to format the Date without the time and your index supports only Int dates, like number of days). That's possible, the user just need to provide a NumberFormat that will convert String to whatever Number object the user wants. 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: 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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vinicius Barros updated LUCENE-1768:
Attachment: week5-6.patch
This patch includes code from week 5 and 6. Sorry for taking so long to submit
a new patch, but I was hitting many problems when I finally started run the
junits.
I updated my workspace and got the new changes which use NumericField to add
numeric fields to Documents. So I adapted my junits to that and also refactored
some code to use NumericField.DataType in NumericConfig, instead of using
Class? extends Number when specifying the NumericConfig type.
I added a junit class (TestNumericQueryParser). I reused some LuceneTestCase
methods, mainly the ones that generate random things. I took sometime to get
where I wanted, I was hitting many problems when using dates in range. In the
end, I liked the way the junit is running, inputs are very random, mainly the
date formats, using randomly different format styles and locale. I ran the
junit in a loop 1000 times and I got no error, so I think it's pretty stable
now. Uwe, please, take a look and let me know what you think about it.
testInclusiveLowerRangeQuery and testInclusiveUpperRangeQuery are commented
since I found that StandardQueryParser is not supporting mixed include
syntaxes, such as {1 TO 2]. Shouldn't it be supported? I don't see why not.
Also, the query parser is not supporting open ended range queries, such as [...
to 3].
I am checking Grant license to ASF for inclusion in ASF works (as per the
Apache License ยง5) now, because I think the patch is finally ready to be
checked in. I ran Lucene top level ant and it finished successfully.
I will work on creating javadocs now.
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: Adriano Crestani
Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 4.0
Attachments: 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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week4.patch This patch includes the builder for numeric range queries. This week I intend to start writing junits. 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.patch, week2.patch, week3.patch, week4.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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week3.patch This patch includes: -changes suggested by Adriano and Uwe: -remvoed @Override -applied Lucene codestyle -created constructor to NumericQueryNode -added ASF header to new classes -Implemented new NumericQueryNodeProcessor and NumericRangeQueryNodeProcessor 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.patch, week2.patch, week3.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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week2.patch This is the patch for my second week of work. 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.patch, week2.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13044624#comment-13044624 ] Vinicius Barros commented on LUCENE-1768: - The second patch includes the week1 changes plus: implemented classes to support numeric configuration in query parser I was not sure what to do about the locale. The locale is required by EscapeQuerySyntax.escape, which seems to escape characters so they don't mix with query parser's operators. The code I used locale I copied from FieldQueryNode, which uses the escaper and passes the default locale, however, other nodes as RegexpQueryNode ignore the escaper and just return the plain text. I was not sure what to do, then I am forcing the locale to ENGLISH now. I also took a long time to figure out how to implement the numeric configuration, it seemed to me the best approach was to copy the way FieldBoostAttribute is configured. It's complex, but it's the only way I found without doing any ugly workaround. Please, take a look at the code and give me some suggestions in case you thing I need to change something. PS: the patch is now created from the trunk folder, as Uwe suggested Thanks! 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.patch, week2.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13044625#comment-13044625 ] Vinicius Barros commented on LUCENE-1768: - ah, one more thing. Uwe, what is Generics Policeman Point of View? 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.patch, week2.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13041961#comment-13041961 ] Vinicius Barros commented on LUCENE-1768: - Hi Uwe, Thanks for quickly reviewing the patch. Yes, I am using trunk's code. I will do the changes you suggested and include in the next patch. 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.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
[jira] [Updated] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vinicius Barros updated LUCENE-1768: Attachment: week1.patch This patch includes the work I did this first week. I started with one of the project's objective: restructure RangeQueryNode and its related classes to support number and text range queries. I created some querynode interfaces, such as ValueQueryNode that abstract the value a leaf node may hold, since now, leaf nodes do not only hold text anymore, but also number values. Let me know if you have any questions or any suggestions about the code. I expect I created the patch correctly, as it's the first time I play with subversion 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 Attachments: week1.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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016653#comment-13016653 ] Vinicius Barros commented on LUCENE-1768: - Thanks for reviewing it Adriano. I updated the proposal to clarify it's the contrib query parser. 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13015260#comment-13015260 ] Vinicius Barros commented on LUCENE-1768: - Hi, Thanks Uwe and Adriano, I finally finished and submitted my proposal to this project, please, take a look and tell me if I need to change something. My linkid is viniciusbarros Sorry for taking so long to submit it, but just got a free time this weekend, college stuffs are keeping me busy. Uwe: I added to my proposal the idea of enabling the user to enter a query that searches for a single numeric value, example, age:19. About DateTools, I think this can be decided later, in the end it's just a class with some format options the user may choose. Anyway, the numeric already have a pre-defined form to format number in strings before indexing right?! Take a look to what I have defined in my proposal, where I allow the user to specify a Format object, which is used by the query parser to parse the string value entered by the user to Number. Please, let me know if I am not getting something here. 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: Adriano Crestani Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor Fix For: 4.0 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
[jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13011914#comment-13011914
]
Vinicius Barros commented on LUCENE-1768:
-
Hi Uwe and Adriano,
I read the description, javadocs about the numeric support and the new query
parser and all the comments here. Let me try to summarize what needs to be done
here:
-figure out a way to configure in query parser which fields are numeric, and
for each of these fields, the numeric type must also be defined...from the
comments, it seems the best way to do this is using a map field-NumericType
-create a NumericQueryNodeProcessor that converts ParametricRangeQueryNode to
NumericRangeQueryNode, when its field is a numeric field. This processor should
also convert the range string values to numeric values based on the NumericType
-create a NumericRangeQueryNodeBuilder, which will build which will build
NumericRangeQuery objects from NumericRangeQueryNode objects
-rename RangeQueryNode to TermRangeQueryNode as it will only be used for string
-create a NumericRangeQueryNode which will be used for any non-string range
query
-merge DateTools with a new NumericTools class. Does that make sense? I am not
sure if I got everything correctly here.
Some questions below:
{quote}
Luis:
create the new NumericRangeQueryNode that extends from TermRangeQueryNode
{quote}
-should NumericRangeQueryNode extends TermRangeQueryNode? I don't see any
reason for that, since one will hold Number values and the other String values
-I remember the old date query, using strings, used to not only allow range
queries, but also term queries (date:2010/10/10), is that correct? Does numeric
fields also support this kind of query? I could only fine NumericRangeQuery,
but no NumericQuery. If the user enters (age:19) in the query, and age is a
numeric field, should the query parser throw an error saying it's not
suppported?
I am planning to create a GSOC proposal for this project, it looks interesting,
very cool this new support to numeric in Lucene, I missed that first time I
used Lucene, maybe because I was used to regular databases. Also, the query
parser uses some design patterns I have been reading about lately, as builders
and processors.
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: Adriano Crestani
Labels: contrib, gsoc, gsoc2011, lucene-gsoc-11, mentor
Fix For: 4.0
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
