[
https://issues.apache.org/jira/browse/LUCENE-6394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14485227#comment-14485227
]
Robert Muir commented on LUCENE-6394:
-------------------------------------
{quote}
Should SpansCell still extend FilterSpans and return always YES? This would
avoid reimplementing Spans from scratch?
{quote}
Definitely not. Its not really filtering the spans at all. it is just a
wrapper. if we want a class for wrapping lets do that separately.
{quote}
It took me some time to compile how FilterSpans.twoPhaseCurrentDocMatches
works, with its infinite loop, conditional fallthrough, etc. maybe it could be
written in a more straightforward way?
{quote}
This code is moved verbatim from SpanPositionCheck.PositionCheckSpan here, so
it can be reused instead of duplicated. Can we refactor it in a separate issue?
My approach here is just removing complex duplicate code that all does the same
thing. I realize its exciting that spans are now "unblocked" after paul's big
rework :), but we need to tackle things incrementally.
> Add two-phase support to SpanNotQuery
> -------------------------------------
>
> Key: LUCENE-6394
> URL: https://issues.apache.org/jira/browse/LUCENE-6394
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Attachments: LUCENE-6394.patch, LUCENE-6394.patch, LUCENE-6394.patch
>
>
> This query is actually a lot like SpanPositionCheckQuery, except it checks
> that each inclusion Spans does not come near the exclusion side.
> Two-phase iteration should just work the inclusion side, deferring positions
> (the overlap checking against exclusion) until necessary.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
