[
https://issues.apache.org/jira/browse/LUCENE-6650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14936739#comment-14936739
]
David Smiley commented on LUCENE-6650:
--------------------------------------
Thanks for the review Adrien.
I'll change the BooleanClause.Occur.FILTER back to MUST only because it feels
more orthogonal to intermixed use with SHOULD in some of those boolean queries.
bq. The one thing that feels awkward to me is this topAcceptDocs which is
top-level to the reader, while everywhere else we work with per-segment
data-structures?
I felt the same, but we don't have a class/abstraction that yields a Bits (or
similar) when given a LeafReaderContext as a parameter. Filter was fairly
close, but it wasn't even perfect since bits() could return null so I had to
have code to build a Bits from the iterator. In the end -- the code here
really wants a Bits -- which is a very simple 2-method interface. So my
feeling is that this is okay, and it's not worthwhile coming up with some new
abstraction to return the Bits per-segment.
> Remove dependency of lucene/spatial on oal.search.Filter
> --------------------------------------------------------
>
> Key: LUCENE-6650
> URL: https://issues.apache.org/jira/browse/LUCENE-6650
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Assignee: David Smiley
> Attachments: LUCENE-6650.patch, LUCENE-6650.patch
>
>
> We should try to remove usage of oal.search.Filter in lucene/spatial. I gave
> it a try but this module makes non-trivial use of filters so I wouldn't mind
> some help here.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
