[
https://issues.apache.org/jira/browse/LUCENE-2669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2669:
----------------------------------
Attachment: LUCENE-2669.patch
Slightly more readable patch: for(;;)-loop removed and so first if check in
accept() negated and used as while-clause instead
Mike you set this as fix 3.1 and 4.0, but 3.1 does not have FilteredTermsEnum.
We cannot fix it there easily, as it uses the old style logic from 3.0.
> NumericRangeQuery.NumericRangeTermsEnum sometimes seeks backwards
> -----------------------------------------------------------------
>
> Key: LUCENE-2669
> URL: https://issues.apache.org/jira/browse/LUCENE-2669
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Reporter: Michael McCandless
> Assignee: Uwe Schindler
> Fix For: 3.1, 4.0
>
> Attachments: LUCENE-2669.patch, LUCENE-2669.patch, LUCENE-2669.patch
>
>
> Subclasses of FilteredTermsEnum are "supposed to" seek forwards only (this
> gives better performance, typically).
> However, we don't check for this, so I added an assert to do that (while
> digging into testing the SimpleText codec) and NumericRangeQuery trips the
> assert!
> Other MTQs seem not to trip it.
> I think I know what's happening -- say NRQ has term ranges a-c, e-f to seek
> to, but then while it's .next()'ing through the first range, the first term
> after c is f. At this point NRQ sees the range a-c is done, and then tries
> to seek to term e which is before f. Maybe NRQ's accept method should detect
> this case (where you've accidentally .next()'d into or possibly beyond the
> next one or more seek ranges)?
--
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]
