[ 
https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041823#comment-13041823
 ] 

Uwe Schindler commented on LUCENE-1768:
---------------------------------------

Hi Vinicius,

thanks for your update! The patch looks correct, I assume it's for Lucene 
trunk? You should  produce them against the top-level directory (below trunk/), 
not the lucene sub-directory (since Lucene was merged with Solr last year).

I have not closely looked at the code (came back from California recently), but 
your refactoring as a first step looks fine. I would only suggest to never 
depend on the default locale (Robert Muir will tell you the same thing), so it 
should respect the local given to query parser.

I will report back, when I had time to look into it, but it looks really fine - 
also from the Generics Policeman Point of View *g*

> 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

Reply via email to