[
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: [email protected]
For additional commands, e-mail: [email protected]
