lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vinicius Barros (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-1768) NumericRange support for new query parser
Date Sat, 06 Aug 2011 05:33:27 GMT

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

Vinicius Barros commented on LUCENE-1768:
-----------------------------------------

I also started working on applying the numeric support to 3x. However I am not sure about
backwards compatibility there.

The problem is that in trunk I had renamed RangeQueryNode to TermRangeQueryNode. Also, TermRangeQueryNode
no longer extends ParametricRangeQueryNode, it now extends AbstractRangeQueryNode. Because
of that, ParametricRangeQueryNodeProcessor returns a TermRangeQueryNode instead of RangeQueryNode.
As you can see, many things the user might expect to still work the same is working completely
different. I see some classes in Lucene use Version, but I don't know exactly how that works
and why standard query parser do not use it. Should it?

Not sure how I should proceed now. Should I ignore the backward compatibility and go ahead
and change how everything behaves or try to make everything backward compatible (not sure
how I could do that without the use of Version).

Do you have any comments on that 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: 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message