[
https://issues.apache.org/jira/browse/LUCENE-6301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348893#comment-14348893
]
Adrien Grand commented on LUCENE-6301:
--------------------------------------
bq. Can it still throw an exception if you use it in such a way as to iterate?
This is to prevent people from mis-using it. Do you know of a similar scorer I
can look at?
You could do the equivalent of what these filters are currently doing by making
the scorer throw an exception when calling nextDoc() or advance(). This would
prevent these queries from being used directly and force consumers to use the
approximation for intersections (which BooleanQuery with MUST/FILTER clauses
will happily do). However beware that while the approximation will be used for
advancing the iterator, score() and freq() will still be called on the scorer.
bq. Do you know of a similar scorer I can look at?
DocValuesTermsQuery should be similar. It cannot advance at all so it returns
an iterator that matches all documents as an approximation and its matches()
impl checks doc values.
bq. I think makeFilter should become deprecated now (as part of this issue).
OK, I'll have a look at it.
> Deprecate Filter
> ----------------
>
> Key: LUCENE-6301
> URL: https://issues.apache.org/jira/browse/LUCENE-6301
> Project: Lucene - Core
> Issue Type: Task
> Reporter: Adrien Grand
> Assignee: Adrien Grand
> Fix For: Trunk, 5.1
>
> Attachments: LUCENE-6301.patch
>
>
> It will still take time to completely remove Filter, but I think we should
> start deprecating it now to state our intention and encourage users to move
> to queries as soon as possible?
--
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
