[
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
Hi Yonik,
here the biginteger variant that works exactly as the old long-based variant
(without your extra checks). This is my favourite solution as it never
overflows and we can maybe extend the whole NumericRange to BigInteger :-) To
reduce object creation, it uses a precalculated (1<<shift) array. I had to
change the logic a little bit as it was broken with precStep=Integer.MAX_VALUE
(OOME).
The tests pass, I did not test your additional test, but I think it should too.
I will test some range splits tomorrow on the solution you found but as far as
i see without trying out, it seem to not work.
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
