Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-1261

Lucene trunk renamed RangeQuery & Co to TermRangeQuery

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.4
    • Component/s: search
    • Labels:
      None

      Description

      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.

      1. SOLR-1261.patch
        5 kB
        Uwe Schindler

        Issue Links

          Activity

          Hide
          gsingers Grant Ingersoll added a comment -

          Bulk close for Solr 1.4

          Show
          gsingers Grant Ingersoll added a comment - Bulk close for Solr 1.4
          Hide
          thetaphi Uwe Schindler added a comment -

          The only problem with the above code are Date Trie Queries, as they would be printed as long values... (effectively toExternal(Long.toString())

          Show
          thetaphi Uwe Schindler added a comment - The only problem with the above code are Date Trie Queries, as they would be printed as long values... (effectively toExternal(Long.toString())
          Hide
          thetaphi Uwe Schindler added a comment -

          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).

          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.

          You misunderstood me. I did not change anything in TermRangeQuery, the code is identical to that before (only ConstantScoreRangeQuery and RangeQuery replaced by TermRangeQuery).

          What I have done as new contribution in this patch is, that I extended QueryParsing.java to print out the correct numeric query representation (also using toExternal and so on):

          if (query instanceof NumericRangeQuery) {
                NumericRangeQuery q = (NumericRangeQuery)query;
                String fname = q.getField();
                FieldType ft = writeFieldName(fname, schema, out, flags);
                out.append( q.includesMin() ? '[' : '{' );
                Number lt = q.getMin();
                Number ut = q.getMax();
                if (lt==null) {
                  out.append('*');
                } else {
                  writeFieldVal(lt.toString(), ft, out, flags);
                }
          
                out.append(" TO ");
          
                if (ut==null) {
                  out.append('*');
                } else {
                  writeFieldVal(ut.toString(), ft, out, flags);
                }
          
                out.append( q.includesMax() ? ']' : '}' );
          }
          
          Show
          thetaphi Uwe Schindler added a comment - 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 ). 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. You misunderstood me. I did not change anything in TermRangeQuery, the code is identical to that before (only ConstantScoreRangeQuery and RangeQuery replaced by TermRangeQuery). What I have done as new contribution in this patch is, that I extended QueryParsing.java to print out the correct numeric query representation (also using toExternal and so on): if (query instanceof NumericRangeQuery) { NumericRangeQuery q = (NumericRangeQuery)query; String fname = q.getField(); FieldType ft = writeFieldName(fname, schema, out, flags); out.append( q.includesMin() ? '[' : '{' ); Number lt = q.getMin(); Number ut = q.getMax(); if (lt== null ) { out.append('*'); } else { writeFieldVal(lt.toString(), ft, out, flags); } out.append( " TO " ); if (ut== null ) { out.append('*'); } else { writeFieldVal(ut.toString(), ft, out, flags); } out.append( q.includesMax() ? ']' : '}' ); }
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          Committed revision 794328.

          This has been committed as part of SOLR-940 and other related issues.

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - Committed revision 794328. This has been committed as part of SOLR-940 and other related issues.
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          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).

          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.

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - 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 ). 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.
          Hide
          thetaphi Uwe Schindler added a comment -

          Attached is a patch, that does this (untested, but should work).

          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).

          Show
          thetaphi Uwe Schindler added a comment - Attached is a patch, that does this (untested, but should work). 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 ).
          Hide
          thetaphi Uwe Schindler added a comment -

          This change is related to Lucenes new numeric search capabilities and some API cleanup because of this.

          Show
          thetaphi Uwe Schindler added a comment - This change is related to Lucenes new numeric search capabilities and some API cleanup because of this.

            People

            • Assignee:
              shalinmangar Shalin Shekhar Mangar
              Reporter:
              thetaphi Uwe Schindler
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development