[
https://issues.apache.org/jira/browse/LUCENE-4304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13433378#comment-13433378
]
Uwe Schindler commented on LUCENE-4304:
---------------------------------------
+1 - This class horrified me while refactoring IndexReaders beginning of the
year! I already patched it to better fit in here, but FilterAtomicReader or a
custom codec is the way to go.
bq. I think merging shouldn't change postings as a side-effect (by default,
anyway, since a custom PF can of course override merge and do whatever it
wants).
If you really want to do this, use a FilterAtomicReader and rewrite payloads
while doing IW.addIndexes(FilterAtomicReader...)
> Remove PayloadProcessProvider
> -----------------------------
>
> Key: LUCENE-4304
> URL: https://issues.apache.org/jira/browse/LUCENE-4304
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Michael McCandless
>
> Now that we have pluggable codecs (well, PostingsFormat), an app should use a
> custom PostingsFormat if it really must change payloads while merging.
> Alternatively, use a FilteredIndexReader to modify anything during addIndexes
> (eg the facets use case, modifying payloads).
> Since this capability can be handled by existing more-generic functions I
> don't see why we need to keep PPP around in core. PPP is also fragile
> because an app generally has no visibility on when a merge commits so it
> can't know if the payloads it retrieves are pre or post PPP.
> I think merging shouldn't change postings as a side-effect (by default,
> anyway, since a custom PF can of course override merge and do whatever it
> wants).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
