[
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 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]
