[ 
https://issues.apache.org/jira/browse/SOLR-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731576#action_12731576
 ] 

Shalin Shekhar Mangar commented on SOLR-1261:
---------------------------------------------

{quote}In my opinion, QueryParsing.java should now also be able to create a 
string representation of NumericRangeQueries, I did this, too (related to 
SOLR-940).{quote}

The only problem is that Solr always prints out the value given by 
FieldType#toExternal which TermRangeQuery#toString wouldn't know about. So I 
guess we should leave it as is.

> Lucene trunk renamed RangeQuery & Co to TermRangeQuery
> ------------------------------------------------------
>
>                 Key: SOLR-1261
>                 URL: https://issues.apache.org/jira/browse/SOLR-1261
>             Project: Solr
>          Issue Type: Task
>          Components: search
>    Affects Versions: 1.4
>            Reporter: Uwe Schindler
>         Attachments: SOLR-1261.patch
>
>
> I committed shortly ago LUCENE-1713, that renamed RangeQuery to 
> TermRangeQuery (and also RangeFilter -> TermRangeFilter). The API of the old 
> deprecated RangeQuery and RangeFilter classes was reverted to the state of 
> Lucene 2.4, only the new classes contain the improvements of 2.9. So Solr 
> will not compile anymore, because the new ctors of RangeQuery and 
> setConstantScoreRewrite are no longer available, but were already included 
> into Solr.
> This can be solved by simply replacing RangeQuery to TermRangeQuery in the 
> source.
> There were some minor cleanups with the API, because there must not be any 
> strange methods anmes because of BW compatibility in the new class. Also all 
> ctors using Term are only available in the deprecated classes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to