[
https://issues.apache.org/jira/browse/LUCENE-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2541:
----------------------------------
Attachment: LUCENE-2541-uwe.patch
Here my solution (its yours), but different test. The tests in
NumericRangeQuery also verify that the range is really covered completely, so I
tend to use these tests.
I just tried some values, we have to add randomness and other precsteps. Its
just a start before going to sleep - will extend tests tomorrow, to test
different precSteps.
Yonik: The bug appears with 2^63 and, yes, it depends on precStep. What I meant
is, that the outer bounds must be in the "bracket" that covers the 2^63 limit.
So with larger precision steps, also smaller values overflow (but only for
longs, ints are safe, as they internally also use longs).
> NumericRangeQuery errors with endpoints near long min and max values
> --------------------------------------------------------------------
>
> Key: LUCENE-2541
> URL: https://issues.apache.org/jira/browse/LUCENE-2541
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 2.9
> Reporter: Koji Sekiguchi
> Assignee: Uwe Schindler
> Attachments: LUCENE-2541-uwe.patch, LUCENE-2541.patch,
> LUCENE-2541.patch, TestNumericRangeQuery.java
>
>
> This problem first reported in Solr:
> http://lucene.472066.n3.nabble.com/range-query-on-TrieLongField-strange-result-tt970974.html#a970974
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
