[
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-BigDecimal.patch
LUCENE-2541-uwe-longs.patch
Here two final variants:
- one with BigDecimals and improved range spliut logic (I like this patch more!)
- one with Yoniks fix
Both patches contain the same tests that pass. I converted Yoniks test and
added to TestNumericUtils, which tests more intensive, if the spliutted range
is correct: I ensures that all sub range bounds are inside the whole range and
that there are no holes in the range. It also checks (important for yoniks fix)
that one example range is splitted into the correct sub-ranges. I removed
inverse ranges from yoniks patch, as they can never break (NRQ and also
splitRange exits early if lower > upper). Also to enable the tests for ranges
without holes, the bitset size cannot grow unlimited, so the maximum length of
the range is limited to 8192*1024.
I still did not use autoboxing and varargs in the TestNumericUtils, as now this
patch should apply easy to 2.9 (with minor changes), so the initial merging
works. After committing this to all branches, i would update 3.x and trunk to
use varargs and autoboxing, which makes the test more readable.
Without NumericUtils fix, the new testcases both fail.
I just want to know: Which patch do you prefer? Else this is ready to commit
with the cleanup work in 3.x and trunk later.
> 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
> Fix For: 2.9.4, 3.0.3, 3.1, 4.0
>
> Attachments: LUCENE-2541-uwe-BigDecimal.patch,
> LUCENE-2541-uwe-longs.patch, 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]
