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

can't query against negative float or double values when indexed="false" docValues="true" multiValued="false"

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.5.1, 5.6, 6.0, 6.1, master (7.0)
    • Component/s: None
    • Labels:
      None

      Description

      Haven't dug into this yet, but something is evidently wrong in how the DocValues based queries get build for single valued float or double fields when negative numbers are involved.

      Steps to reproduce...

      $ bin/solr -e schemaless -noprompt
      ...
      $ curl -X POST -H 'Content-type:application/json' --data-binary '{ "add-field":{ "name":"f_dv_multi", "type":"tfloat", "stored":"true", "indexed":"false", "docValues":"true", "multiValued":"true" }, "add-field":{ "name":"f_dv_single", "type":"tfloat", "stored":"true", "indexed":"false", "docValues":"true", "multiValued":"false" } }' http://localhost:8983/solr/gettingstarted/schema
      {
        "responseHeader":{
          "status":0,
          "QTime":84}}
      $ curl -X POST -H 'Content-type:application/json' --data-binary '[{"id":"test", "f_dv_multi":-4.3, "f_dv_single":-4.3}]' 'http://localhost:8983/solr/gettingstarted/update/json/docs?commit=true'
      {"responseHeader":{"status":0,"QTime":57}}
      $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:"-4.3"'
      {
        "responseHeader":{
          "status":0,
          "QTime":5,
          "params":{
            "q":"f_dv_multi:\"-4.3\""}},
        "response":{"numFound":1,"start":0,"docs":[
            {
              "id":"test",
              "f_dv_multi":[-4.3],
              "f_dv_single":-4.3,
              "_version_":1512962117004689408}]
        }}
      $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:"-4.3"'
      {
        "responseHeader":{
          "status":0,
          "QTime":5,
          "params":{
            "q":"f_dv_single:\"-4.3\""}},
        "response":{"numFound":0,"start":0,"docs":[]
        }}
      

      Explicit range queries (which is how numeric "field" queries are implemented under the cover) are equally problematic...

      $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_multi:%5B-4.3+TO+-4.3%5D'
      {
        "responseHeader":{
          "status":0,
          "QTime":0,
          "params":{
            "q":"f_dv_multi:[-4.3 TO -4.3]"}},
        "response":{"numFound":1,"start":0,"docs":[
            {
              "id":"test",
              "f_dv_multi":[-4.3],
              "f_dv_single":-4.3,
              "_version_":1512962117004689408}]
        }}
      $ curl 'http://localhost:8983/solr/gettingstarted/query?q=f_dv_single:%5B-4.3+TO+-4.3%5D'
      {
        "responseHeader":{
          "status":0,
          "QTime":0,
          "params":{
            "q":"f_dv_single:[-4.3 TO -4.3]"}},
        "response":{"numFound":0,"start":0,"docs":[]
        }}
      
      1. SOLR-8082.patch
        34 kB
        Steve Rowe
      2. SOLR-8082.patch
        34 kB
        Yonik Seeley
      3. SOLR-8082.patch
        33 kB
        Ishan Chattopadhyaya
      4. SOLR-8082.patch
        20 kB
        Ishan Chattopadhyaya
      5. SOLR-8082.patch
        19 kB
        Ishan Chattopadhyaya
      6. SOLR-8082.patch
        19 kB
        Ishan Chattopadhyaya
      7. SOLR-8082.patch
        16 kB
        Ishan Chattopadhyaya
      8. SOLR-8082.patch
        10 kB
        Hoss Man

        Issue Links

          Activity

          Hide
          hossman Hoss Man added a comment -

          the attached patch demonstrates the breadth of the problems i've found with queries against negative values in both float and double based docvalues (only) fields – ie: queries in which DocValuesRangeQuery is used instead of the inverted index (via NumericRangeQuery)

          I'm still not really clear what the root bug / fix is, but best i can tell this is ultimately about a disconnect between how the DocValuesRangeQuery objects are built at query time (using NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong) vs how the NumericDocValuesField objects are build at index time (using Float.floatToIntBits and Double.doubleToLongBits)

          My bare bones understanding is that both places should be using NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong – but (besides being a back compat break on how the values are written to disk) if that's the case then why does sorting work for negative float values today? (see DocValuesTest.testDocValuesSorting2, which – in addition to many faceting tests – broke when i experimented with using NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong to build the NumericDocValuesField in TrieField.createFields)

          Can anyone explain to me:

          • when/why floatToIntBits & doubleToLongBits should be used instead of floatToSortableInt & doubleToSortableLong
          • how to fix these tests so they pass and queries against negative float / double values will work?
          Show
          hossman Hoss Man added a comment - the attached patch demonstrates the breadth of the problems i've found with queries against negative values in both float and double based docvalues (only) fields – ie: queries in which DocValuesRangeQuery is used instead of the inverted index (via NumericRangeQuery) I'm still not really clear what the root bug / fix is, but best i can tell this is ultimately about a disconnect between how the DocValuesRangeQuery objects are built at query time (using NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong) vs how the NumericDocValuesField objects are build at index time (using Float.floatToIntBits and Double.doubleToLongBits) My bare bones understanding is that both places should be using NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong – but (besides being a back compat break on how the values are written to disk) if that's the case then why does sorting work for negative float values today? (see DocValuesTest.testDocValuesSorting2, which – in addition to many faceting tests – broke when i experimented with using NumericUtils.floatToSortableInt and NumericUtils.doubleToSortableLong to build the NumericDocValuesField in TrieField.createFields) Can anyone explain to me: when/why floatToIntBits & doubleToLongBits should be used instead of floatToSortableInt & doubleToSortableLong how to fix these tests so they pass and queries against negative float / double values will work?
          Hide
          hossman Hoss Man added a comment -

          updated summary & description to capture new info (affects doubles, only seems to affect negative values)

          Show
          hossman Hoss Man added a comment - updated summary & description to capture new info (affects doubles, only seems to affect negative values)
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Probably related to SOLR-8838.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Probably related to SOLR-8838 .
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          Here's a summary of my understanding / observations:

          1. Floats and doubles need to be converted to longs before writing them to NumericDocValues.
          2. We have two options, Double.doubleToLongBits() and NumericUtils.doubleToSortableLong(). For positive doubles, both these methods return the same long value, but different ones for negative doubles.
          3. Currently, we use Double.doubleToLongBits() to write these doubles/floats. Hence, to use term query against such docValues, we should use the same method with the query value, but current code uses NumericUtils.doubleToSortableLong() during querying and hence term queries against negative values fail. Similarly, range queries also fail when min is negative.
          4. I tried changing initial writing logic to use NumericUtils.doubleToSortableLong(). With this change, both term queries and range queries work, but sorting fails (when there are negative values). That is counter intuitive, since the individual long values themselves are in sorted order. Since this is an intrusive change that breaks backcompat, I didn't investigate deeper to understand why this is happening.
          5. To arrive at a least intrusive fix, I tried changing the range query logic to split out the queries into two distinct ranges (negatives and positives) using a boolean query. I had to do this since the Double.doubleToLongBits() values are not monotonically increasing (they are decreasing for Double.MIN_VALUE to 0, but increasing for 0 to Double.MAX_VALUE).

          Attached the patch for the last point, which I think is the least intrusive way to pull things together so that they work. When the range query crosses the 0 boundary, there are two dv range queries which is less efficient, but better than not working at all (which is the case today). The patch passes the tests, but it might benefit from some neater refactoring.

          Hoss Man Can you please review? Do you think there's a cleaner way to do this?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited Here's a summary of my understanding / observations: Floats and doubles need to be converted to longs before writing them to NumericDocValues. We have two options, Double.doubleToLongBits() and NumericUtils.doubleToSortableLong(). For positive doubles, both these methods return the same long value, but different ones for negative doubles. Currently, we use Double.doubleToLongBits() to write these doubles/floats. Hence, to use term query against such docValues, we should use the same method with the query value, but current code uses NumericUtils.doubleToSortableLong() during querying and hence term queries against negative values fail. Similarly, range queries also fail when min is negative. I tried changing initial writing logic to use NumericUtils.doubleToSortableLong(). With this change, both term queries and range queries work, but sorting fails (when there are negative values). That is counter intuitive, since the individual long values themselves are in sorted order. Since this is an intrusive change that breaks backcompat, I didn't investigate deeper to understand why this is happening. To arrive at a least intrusive fix, I tried changing the range query logic to split out the queries into two distinct ranges (negatives and positives) using a boolean query. I had to do this since the Double.doubleToLongBits() values are not monotonically increasing (they are decreasing for Double.MIN_VALUE to 0, but increasing for 0 to Double.MAX_VALUE). Attached the patch for the last point, which I think is the least intrusive way to pull things together so that they work. When the range query crosses the 0 boundary, there are two dv range queries which is less efficient, but better than not working at all (which is the case today). The patch passes the tests, but it might benefit from some neater refactoring. Hoss Man Can you please review? Do you think there's a cleaner way to do this?
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          if that's the case then why does sorting work for negative float values today?

          It is something even I was unable to figure out and surprises me, since the converted long values currently written to disk (as a result of Double.doubleToLongBits()) are not monotonic.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited if that's the case then why does sorting work for negative float values today? It is something even I was unable to figure out and surprises me, since the converted long values currently written to disk (as a result of Double.doubleToLongBits()) are not monotonic.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Tackling some boundary cases, added another test (testFloatRangeQuery). This is still WIP, I'm working on:

          1. A randomized test for ranges
          2. Cleanup / refactor
          3. Better handling and testing around inclusion operators

          This approach looks clumsy, but might be the least intrusive way of getting this to work? Once done with this patch, I'll take a shot at evaluating, once again, as to possibly rewriting the logic for writing floats/doubles as longs into docValues.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Tackling some boundary cases, added another test (testFloatRangeQuery). This is still WIP, I'm working on: A randomized test for ranges Cleanup / refactor Better handling and testing around inclusion operators This approach looks clumsy, but might be the least intrusive way of getting this to work? Once done with this patch, I'll take a shot at evaluating, once again, as to possibly rewriting the logic for writing floats/doubles as longs into docValues.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updated the patch, refactored the fix and a test. Still WIP and the above TODO items are not here.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updated the patch, refactored the fix and a test. Still WIP and the above TODO items are not here.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Updating the patch. This contains a randomized test, which I am currently beasting now.
          This depends on a patch for a bug I found during testing this, LUCENE-7111.

          If the beasting goes fine, I think this is a fix that behaves correctly. But, still not sure if this is the best fix to have, since there possibly exists another alternative (which I'll look into after this) to write the longs in sortable order itself.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Updating the patch. This contains a randomized test, which I am currently beasting now. This depends on a patch for a bug I found during testing this, LUCENE-7111 . If the beasting goes fine, I think this is a fix that behaves correctly. But, still not sure if this is the best fix to have, since there possibly exists another alternative (which I'll look into after this) to write the longs in sortable order itself.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment - - edited

          Building a boolean query is the slowest option of all (will look up all the values twice and has overhead)... coverting to a float/double would be faster (that should actually be a no-op... so it would be down to how fast the floating point comparisons are vs long comparisons). If we did want to keep things in "long" space rather than converting, then perhaps just create our own version that does an additional comparison when needed.

          I was going to suggest that we could also just try the built-in range support in valuesource
          FunctionValues.getRangeScorer()... but I forgot to bring back the "only match docs with a value" patch from heliosearch.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - - edited Building a boolean query is the slowest option of all (will look up all the values twice and has overhead)... coverting to a float/double would be faster (that should actually be a no-op... so it would be down to how fast the floating point comparisons are vs long comparisons). If we did want to keep things in "long" space rather than converting, then perhaps just create our own version that does an additional comparison when needed. I was going to suggest that we could also just try the built-in range support in valuesource FunctionValues.getRangeScorer()... but I forgot to bring back the "only match docs with a value" patch from heliosearch.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Building a boolean query is the slowest option of all (will look up all the values twice and has overhead)... coverting to a float/double would be faster

          Do you mean that instead of using the DocValuesRangeQuery.newLongRange(), we write something on our own which converts the longs back to floats/doubles and then compares those floats/doubles?

          If we did want to keep things in "long" space rather than converting, then perhaps just create our own version that does an additional comparison when needed.

          Do you think the NumericUtils.doubleToSortableLong() is a good choice for converting float/double to longs, instead of Double.doubleToLongBits() which is currently used? I think this would ensure that the range queries would just work out of the box without such handling of special cases. Also, is it okay to change the way we convert floats/doubles to longs in terms of backward compatibility?

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Building a boolean query is the slowest option of all (will look up all the values twice and has overhead)... coverting to a float/double would be faster Do you mean that instead of using the DocValuesRangeQuery.newLongRange(), we write something on our own which converts the longs back to floats/doubles and then compares those floats/doubles? If we did want to keep things in "long" space rather than converting, then perhaps just create our own version that does an additional comparison when needed. Do you think the NumericUtils.doubleToSortableLong() is a good choice for converting float/double to longs, instead of Double.doubleToLongBits() which is currently used? I think this would ensure that the range queries would just work out of the box without such handling of special cases. Also, is it okay to change the way we convert floats/doubles to longs in terms of backward compatibility?
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Do you mean that instead of using the DocValuesRangeQuery.newLongRange(), we write something on our own which converts the longs back to floats/doubles and then compares those floats/doubles?

          Yeah, that's one way.
          But maybe we should go ahead and fix ValueSourceRangeFilter to not match documents w/o a value in the field. It's arguably a bug (and only existed historically because we didn't have info about what fields had a value for numerics, and didn't have exists()) and 6.0 is the perfect time to make the change.

          Do you think the NumericUtils.doubleToSortableLong() is a good choice for converting float/double to longs, instead of Double.doubleToLongBits() which is currently used?

          Both have their advantages... while sortable longs might be convenient when operating in the "long" space, it would slow things down when converting back to a double.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Do you mean that instead of using the DocValuesRangeQuery.newLongRange(), we write something on our own which converts the longs back to floats/doubles and then compares those floats/doubles? Yeah, that's one way. But maybe we should go ahead and fix ValueSourceRangeFilter to not match documents w/o a value in the field. It's arguably a bug (and only existed historically because we didn't have info about what fields had a value for numerics, and didn't have exists()) and 6.0 is the perfect time to make the change. Do you think the NumericUtils.doubleToSortableLong() is a good choice for converting float/double to longs, instead of Double.doubleToLongBits() which is currently used? Both have their advantages... while sortable longs might be convenient when operating in the "long" space, it would slow things down when converting back to a double.
          Hide
          hossman Hoss Man added a comment -

          Building a boolean query is the slowest option of all (will look up all the values twice and has overhead)

          "A patch in jira ready to be committed is worth two hypothetical patches no one has contributed yet."

          As things stand today, a query where either end point is less then 0 is completely broken – a "slow" boolean query that is correct sounds better to me then the broken behavior – even if it's just a short term gap for 6.0 and we have plans for a better solution down the road. Particularly since (unless i'm missing something) any existing situation where the code works correctly today will continue to work correctly with the same performance after this patch (ie: purely positive ranges will continue to be implemented w/o a BQ using a purely positive range query.)

          But maybe we should go ahead and fix ValueSourceRangeFilter to not match documents w/o a value in the field. It's arguably a bug

          That seems like it should be broken out into a distinct $new_jira since it has larger implications/impacts. (if we want to make this issue blocked by $new_jira then so be it, but they should still be distinct issues)

          Show
          hossman Hoss Man added a comment - Building a boolean query is the slowest option of all (will look up all the values twice and has overhead) "A patch in jira ready to be committed is worth two hypothetical patches no one has contributed yet." As things stand today, a query where either end point is less then 0 is completely broken – a "slow" boolean query that is correct sounds better to me then the broken behavior – even if it's just a short term gap for 6.0 and we have plans for a better solution down the road. Particularly since (unless i'm missing something) any existing situation where the code works correctly today will continue to work correctly with the same performance after this patch (ie: purely positive ranges will continue to be implemented w/o a BQ using a purely positive range query.) But maybe we should go ahead and fix ValueSourceRangeFilter to not match documents w/o a value in the field. It's arguably a bug That seems like it should be broken out into a distinct $new_jira since it has larger implications/impacts. (if we want to make this issue blocked by $new_jira then so be it, but they should still be distinct issues)
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          a "slow" boolean query that is correct sounds better to me then the broken behavior

          Hopefully no one is suggesting that we not fix this (somehow) for 6.0
          I was just using the opportunity to fix another bug that would also help with this one.

          That seems like it should be broken out

          That's what SOLR-8867 is about.

          Show
          yseeley@gmail.com Yonik Seeley added a comment - a "slow" boolean query that is correct sounds better to me then the broken behavior Hopefully no one is suggesting that we not fix this (somehow) for 6.0 I was just using the opportunity to fix another bug that would also help with this one. That seems like it should be broken out That's what SOLR-8867 is about.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Hopefully no one is suggesting that we not fix this (somehow) for 6.0

          I think seems this like a bad enough bug for us to fix right away, also given our latest push for using all fields with docvalues and also given the push for having some of them unstored. With range queries completely broken, I think we should push for it for 6.0, or a 6.0.1 if not ready right away. I think it is safe to do so, as long as a targeted fix doesn't make things worse than what it already is. What do you think? Yonik Seeley Hoss Man

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Hopefully no one is suggesting that we not fix this (somehow) for 6.0 I think seems this like a bad enough bug for us to fix right away, also given our latest push for using all fields with docvalues and also given the push for having some of them unstored. With range queries completely broken, I think we should push for it for 6.0, or a 6.0.1 if not ready right away. I think it is safe to do so, as long as a targeted fix doesn't make things worse than what it already is. What do you think? Yonik Seeley Hoss Man
          Hide
          yseeley@gmail.com Yonik Seeley added a comment - - edited

          Here's an updated patch that uses the same method as

          {!frange}

          for a range query. I took the conservative approach and just replaced the boolean query in the previous patch, leaving the previous non-negative ranges untouched.

          Thanks to the excellent tests in the previous patches, it helped uncover a limitation in ValueSourceRangeFilter that prevented including infinite endpoints.

          I had to make one change to the tests: I removed -0 as a special value in testFloatAndDoubleRangeQueryRandom. Since -0 == +0, any range including one should include the other. I don't think we should support or guarantee behavior of "different zeros" in any case - way to many potential bugs, and it limits us from an implementation standpoint (different bit patterns for equivalent values).

          Show
          yseeley@gmail.com Yonik Seeley added a comment - - edited Here's an updated patch that uses the same method as {!frange} for a range query. I took the conservative approach and just replaced the boolean query in the previous patch, leaving the previous non-negative ranges untouched. Thanks to the excellent tests in the previous patches, it helped uncover a limitation in ValueSourceRangeFilter that prevented including infinite endpoints. I had to make one change to the tests: I removed -0 as a special value in testFloatAndDoubleRangeQueryRandom. Since -0 == +0, any range including one should include the other. I don't think we should support or guarantee behavior of "different zeros" in any case - way to many potential bugs, and it limits us from an implementation standpoint (different bit patterns for equivalent values).
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Thanks Yonik, the patch looks good. The test is passing for me.
          Do you think we should rely on FunctionRangeQuery for the entire number line, or should we just use this for the negative range? To me, both looked similar in terms of performance.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Thanks Yonik, the patch looks good. The test is passing for me. Do you think we should rely on FunctionRangeQuery for the entire number line, or should we just use this for the negative range? To me, both looked similar in terms of performance.
          Hide
          yseeley@gmail.com Yonik Seeley added a comment -

          Do you think we should rely on FunctionRangeQuery for the entire number line

          Perhaps eventually? I was trying to be conservative and not create any performance regressions for the stuff that does work.
          I don't have time for performance tests right now (and I know from looking that the frange stuff can be sped up as well in a lot of places... we no longer need to wrap a filter, exists() looks slow in many function value implementations, etc.) May be better to tackle that stuff after 6.0

          Show
          yseeley@gmail.com Yonik Seeley added a comment - Do you think we should rely on FunctionRangeQuery for the entire number line Perhaps eventually? I was trying to be conservative and not create any performance regressions for the stuff that does work. I don't have time for performance tests right now (and I know from looking that the frange stuff can be sped up as well in a lot of places... we no longer need to wrap a filter, exists() looks slow in many function value implementations, etc.) May be better to tackle that stuff after 6.0
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited

          Indeed! +1 to fixing the issue for 6.0 with the current patch (except for the stale comment If min is negative (or -0d) and max is positive (or +0d), then issue two range queries, which was left over an older patch).

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - - edited Indeed! +1 to fixing the issue for 6.0 with the current patch (except for the stale comment If min is negative (or -0d) and max is positive (or +0d), then issue two range queries , which was left over an older patch).
          Hide
          steve_rowe Steve Rowe added a comment -

          Patch with a few minor cleanups:

          • In TrieField.getRangeQueryForFloatDoubleDocValues():
            • Made constants for invariants (bits for infinities and zeros), in case the compiler isn't smart enough to do that.
            • Added parens in a couple of expressions to improve legibility.
          • In DocValuesTest:
            • In testFloatAndDoubleRangeQueryRandom():
              • Converted several fieldName[i].equals("floatdv") ? ... : ... trinary operators to use (float,double) tuples (like the other values in this test), using lambdas.
            • In testFloatAndDoubleRangeQuery():
              • negativeInfinity[1] fixed: Float->Double
          • +1 to fixing the issue for 6.0 with the current patch (except for the stale comment If min is negative (or -0d) and max is positive (or +0d), then issue two range queries, which was left over an older patch).

            • The patch fixes this too: s/two range queries/FunctionRangeQuery/

          I'll commit tomorrow if no objections and nobody else gets to it first.

          Show
          steve_rowe Steve Rowe added a comment - Patch with a few minor cleanups: In TrieField.getRangeQueryForFloatDoubleDocValues() : Made constants for invariants (bits for infinities and zeros), in case the compiler isn't smart enough to do that. Added parens in a couple of expressions to improve legibility. In DocValuesTest : In testFloatAndDoubleRangeQueryRandom() : Converted several fieldName[i].equals("floatdv") ? ... : ... trinary operators to use (float,double) tuples (like the other values in this test), using lambdas. In testFloatAndDoubleRangeQuery() : negativeInfinity[1] fixed: Float->Double +1 to fixing the issue for 6.0 with the current patch (except for the stale comment If min is negative (or -0d) and max is positive (or +0d), then issue two range queries , which was left over an older patch). The patch fixes this too: s/two range queries/FunctionRangeQuery/ I'll commit tomorrow if no objections and nobody else gets to it first.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          +1, LGTM.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - +1, LGTM.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 49d5ec02a2015ddd80059d46788b723b25cb5491 in lucene-solr's branch refs/heads/master from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49d5ec0 ]

          SOLR-8082: Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'

          Show
          jira-bot ASF subversion and git services added a comment - Commit 49d5ec02a2015ddd80059d46788b723b25cb5491 in lucene-solr's branch refs/heads/master from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=49d5ec0 ] SOLR-8082 : Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 2668ff5abb16e867f9f770d1da65457161b52cda in lucene-solr's branch refs/heads/branch_6x from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2668ff5 ]

          SOLR-8082: Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'

          Show
          jira-bot ASF subversion and git services added a comment - Commit 2668ff5abb16e867f9f770d1da65457161b52cda in lucene-solr's branch refs/heads/branch_6x from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=2668ff5 ] SOLR-8082 : Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit c3d0276b2f50ca6c1b8dd1298fc2e214c4020dbf in lucene-solr's branch refs/heads/branch_6_0 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c3d0276 ]

          SOLR-8082: Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'

          Show
          jira-bot ASF subversion and git services added a comment - Commit c3d0276b2f50ca6c1b8dd1298fc2e214c4020dbf in lucene-solr's branch refs/heads/branch_6_0 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=c3d0276 ] SOLR-8082 : Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit b2a4003d4c91d2e7e8f46b546bf1ac988b95ad3f in lucene-solr's branch refs/heads/master from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b2a4003 ]

          SOLR-8082: Fix forbidden APIs

          Show
          jira-bot ASF subversion and git services added a comment - Commit b2a4003d4c91d2e7e8f46b546bf1ac988b95ad3f in lucene-solr's branch refs/heads/master from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=b2a4003 ] SOLR-8082 : Fix forbidden APIs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 1d98753e2e3b4a30b799c4a15dcbea25c279979e in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1d98753 ]

          SOLR-8082: Fix forbidden APIs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 1d98753e2e3b4a30b799c4a15dcbea25c279979e in lucene-solr's branch refs/heads/branch_6x from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=1d98753 ] SOLR-8082 : Fix forbidden APIs
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 8c0271cbb8ff82dd3c218bcbad5834905e489273 in lucene-solr's branch refs/heads/branch_6_0 from Uwe Schindler
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c0271c ]

          SOLR-8082: Fix forbidden APIs

          Show
          jira-bot ASF subversion and git services added a comment - Commit 8c0271cbb8ff82dd3c218bcbad5834905e489273 in lucene-solr's branch refs/heads/branch_6_0 from Uwe Schindler [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=8c0271c ] SOLR-8082 : Fix forbidden APIs
          Hide
          anshumg Anshum Gupta added a comment -

          Is this something that should make it's way to 5x too? Yonik Seeley, Steve Rowe, Ishan Chattopadhyaya, and others who were involved here ?

          Show
          anshumg Anshum Gupta added a comment - Is this something that should make it's way to 5x too? Yonik Seeley , Steve Rowe , Ishan Chattopadhyaya , and others who were involved here ?
          Hide
          steve_rowe Steve Rowe added a comment - - edited

          Yes Anshum Gupta, I think it would make sense for 5x too.

          Show
          steve_rowe Steve Rowe added a comment - - edited Yes Anshum Gupta , I think it would make sense for 5x too.
          Hide
          ichattopadhyaya Ishan Chattopadhyaya added a comment -

          Yes, Anshum. I think this should be backported to 5x, and also released as part of 5.5.1.

          Show
          ichattopadhyaya Ishan Chattopadhyaya added a comment - Yes, Anshum. I think this should be backported to 5x, and also released as part of 5.5.1.
          Hide
          steve_rowe Steve Rowe added a comment -

          Reopening to backport to branch_5x and branch_5_5.

          Show
          steve_rowe Steve Rowe added a comment - Reopening to backport to branch_5x and branch_5_5.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 79636a73fc1543fa69bdc5081f3fb20e108fce75 in lucene-solr's branch refs/heads/branch_5x from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=79636a7 ]

          SOLR-8082: Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'

          Show
          jira-bot ASF subversion and git services added a comment - Commit 79636a73fc1543fa69bdc5081f3fb20e108fce75 in lucene-solr's branch refs/heads/branch_5x from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=79636a7 ] SOLR-8082 : Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit f0f9081e345030dd8946fb0141b4315c193a88ce in lucene-solr's branch refs/heads/branch_5_5 from Steve Rowe
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f0f9081 ]

          SOLR-8082: Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'

          Show
          jira-bot ASF subversion and git services added a comment - Commit f0f9081e345030dd8946fb0141b4315c193a88ce in lucene-solr's branch refs/heads/branch_5_5 from Steve Rowe [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=f0f9081 ] SOLR-8082 : Can't query against negative float or double values when indexed='false' docValues='true' multiValued='false'
          Hide
          steve_rowe Steve Rowe added a comment -

          In backporting to branch_5x I had to convert some lambdas to functors (for Java7), and was all ready to push, but when I pulled and got Yonik’s SOLR-8886 changes, there were conflicts, and attempts at merging brought in a shitload of extraneous crap, so I changed strategies: I applied the commit diffs from the two master commits on this issue with patch and fixed up the rejects manually.

          Show
          steve_rowe Steve Rowe added a comment - In backporting to branch_5x I had to convert some lambdas to functors (for Java7), and was all ready to push, but when I pulled and got Yonik’s SOLR-8886 changes, there were conflicts, and attempts at merging brought in a shitload of extraneous crap, so I changed strategies: I applied the commit diffs from the two master commits on this issue with patch and fixed up the rejects manually.
          Hide
          hossman Hoss Man added a comment -

          Manually correcting fixVersion per Step #S5 of LUCENE-7271

          Show
          hossman Hoss Man added a comment - Manually correcting fixVersion per Step #S5 of LUCENE-7271

            People

            • Assignee:
              steve_rowe Steve Rowe
              Reporter:
              hossman Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development