Solr
  1. Solr
  2. SOLR-1261

Lucene trunk renamed RangeQuery & Co to TermRangeQuery

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major 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
          Uwe Schindler added a comment -

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

          Show
          Uwe Schindler added a comment - This change is related to Lucenes new numeric search capabilities and some API cleanup because of this.
          Hide
          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
          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
          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
          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
          Shalin Shekhar Mangar added a comment -

          Committed revision 794328.

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

          Show
          Shalin Shekhar Mangar added a comment - Committed revision 794328. This has been committed as part of SOLR-940 and other related issues.
          Hide
          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
          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
          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
          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
          Grant Ingersoll added a comment -

          Bulk close for Solr 1.4

          Show
          Grant Ingersoll added a comment - Bulk close for Solr 1.4

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development