[
https://issues.apache.org/jira/browse/LUCENE-2541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889407#action_12889407
]
Yonik Seeley commented on LUCENE-2541:
--------------------------------------
Uwe I & discussed some on IRC, but for others following along, I believe the
original patch (checking for overflow) will generate the same ranges as
BigIneger use would.
Here's the logic for the overflow case: nextMaxBound always either stays the
same or decreases.
If nextMinBound does overflow a long, then if we had been using BigInts, it
would be bigger than MAX_LONG, and thus the "nextMinBound>nextMaxBound"
condition would be satisfied to break out of the loop. Thus,
"nextMinBound>nextMaxBound" using Bigints, is equivalent to
"nextMinBound>nextMaxBound || lowerWrapped" using longs.
The same logic applies to the lower bound.
> 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-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: [email protected]
For additional commands, e-mail: [email protected]
