[
https://issues.apache.org/jira/browse/LUCENE-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15212897#comment-15212897
]
Michael McCandless commented on LUCENE-7086:
--------------------------------------------
bq. Even if the strategy is filtering out points, shouldn't that be done in
this class?
I don't think so.
I think filtering away points should be a very explicit choice on the part of
the user, not something that's silently done by default: that kind of leniency
only leads to problems, and was in fact the original reason for opening this
issue.
And exactly how the filtering should happen is not obvious / schema dependent:
should any field that has points be completely removed? Or should the field be
kept when it has other things (doc values, postings), only suppressing that it
has points? When those points fields are removed, should other fields also be
removed?
A user who has indexed points yet also wants to use this slow class needs to
work out how they want to hide their indexed points.
bq. The Javadoc doesn't even warn that this class won't work if your index
contains point fields.
+1 to update the javadocs making this clearer.
> SlowCompositeReaderWrapper does not support point values
> --------------------------------------------------------
>
> Key: LUCENE-7086
> URL: https://issues.apache.org/jira/browse/LUCENE-7086
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Adrien Grand
> Assignee: Michael McCandless
> Fix For: master, 6.0
>
> Attachments: LUCENE-7086.patch, LUCENE-7086.patch
>
>
> SlowCompositeReaderWrapper.getPointValues always returns null. I think this
> is trappy and we should either implement it or throw an
> UnsupportedOperationException instead.
--
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
