[
https://issues.apache.org/jira/browse/LUCENE-6393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395772#comment-14395772
]
Robert Muir commented on LUCENE-6393:
-------------------------------------
{quote}
The problem is that with two phase iteration neither nextDoc() or advance() is
called on SpanPositionCheckQuery.PositionCheckSpans in the testSpanFirstNear
test case, leaving the atFirstInCurrentDoc flag in the wrong state.
Overriding PositionCheckSpans.asTwoPhaseIterator to return null makes the
testSpanFirstNear test case pass.
At the moment I have no idea what the good fix would be.
Perhaps FilterSpans should return null for its two phase iterator just to be on
the safe side.
{quote}
Ok, I understand the issue. Another option to consider is to take the
implementation I added here and move it into filterspans, adding 'abstract
boolean twoPhaseCurrentDocMatches()' to FilterSpans. Then it would have built
in approximation support. I just have to look at NearSpansUnordered.SpansCell
and figure out what the implementation there should be (maybe just 'return
true', i am just not familiar with the code).
> SpanFirstQuery sometimes returns Spans without any positions
> ------------------------------------------------------------
>
> Key: LUCENE-6393
> URL: https://issues.apache.org/jira/browse/LUCENE-6393
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Fix For: Trunk, 5.2
>
> Attachments: LUCENE-6393.patch
>
>
> This hits an assert in SpanScorer because it breaks the javadocs contract of
> Spans.nextStartPosition():
> * Returns the next start position for the current doc.
> * There is always *at least one start/end position* per doc.
> * After the last start/end position at the current doc this returns
> NO_MORE_POSITIONS.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
