[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088110#comment-13088110
]
Adriano Crestani commented on LUCENE-1768:
------------------------------------------
Hi Vinicius,
Thanks for the info, but maybe it is too much details for the changes.txt. Let
me try to simplify it.
(3.x)
New features:
LUCENE-1768: added support for numeric ranges in contrib query parser; added
support for simple numeric queries, such as <age:4>, in contrib query parser
(Vinicius Barros via Uwe Schindler)
Changes in runtime behavior:
LUCENE-1768: StandardQueryConfigHandler now uses NumericFieldConfigListener to
set a NumericConfig to its corresponding FieldConfig; StandardQueryTreeBuilder
now uses DummyQueryNodeBuilder for NumericQueryNodes and uses
NumericRangeQueryNodeBuilder for NumericRangeQueryNodes;
StandardQueryNodeProcessorPipeline now executes NumericQueryNodeProcessor
followed by NumericRangeQueryNodeProcessor right after
LowercaseExpandedTermsQueryNodeProcessor; (Vinicius Barros via Uwe Schindler)
API changes:
LUCENE-1768: setNumericConfigMap and getNumericConfigMap were added to
StandardQueryParser; ParametricRangeQueryNode and
oal.queryParser.standard.nodes.RangeQueryNode now implement
oal.queryParser.core.nodes.RangeQueryNode;
oal.queryParser.core.nodes.RangeQueryNode was deprecated and now extends
TermRangeQueryNode, which extends AbstractRangeQueryNode; ParametricQueryNode
was deprecated; FieldQueryNode now implements the new
FieldValueQueryNode<CharSequence>, which this last one implements
FieldableQueryNode and thew new ValueQueryNode; (Vinicius Barros via Uwe
Schindler)
(trunk)
Changes in runtime behavior:
LUCENE-1768: StandardQueryTreeBuilder uses RangeQueryNodeBuilder for
RangeQueryNodes, since theses two classes were removed;
ParametricRangeQueryNodeProcessor now creates TermRangeQueryNode, instead of
RangeQueryNode, from ParametricRangeQueryNode (Vinicius Barros via Uwe
Schindler)
API Changes:
LUCENE-1768: ParametricRangeQueryNode now implements
RangeQueryNode<FieldQueryNode> instead of RangeQueryNode<ParametricQueryNode>
(Vinicius Barros via Uwe Schindler)
Vinicius, please, review the summary I wrote above, I hope I could simplify
correctly what you summarized. The API Changes for trunk I am assuming you are
going to remove ParametricQueryNode(deprecated) and replace by FieldQueryNode
in that statement.
Uwe, 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: 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: [email protected]
For additional commands, e-mail: [email protected]
