[
https://issues.apache.org/jira/browse/LUCENE-8232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420806#comment-16420806
]
Simon Willnauer commented on LUCENE-8232:
-----------------------------------------
> I'm confused what the abstraction buys us. There is only one implementation.
> This issue claims it allows expert users to do stuff, but its unclear if we
> really want to allow that. Should we really add this? I think if we do, there
> should be two implementations so that we know the api is correct.
a couple of things, I think it's good to have a second impl. There is one in
the a test but I am happy to remove the interface here and make it a concrete
class. The refactoring and cleaning up in ReadersAndUpdates is good I think. We
can then handle and discuss if we want this abstraction in a separate issue. ok
with this [~rcmuir]?
> Separate out PendingDeletes from ReadersAndUpdates
> ---------------------------------------------------
>
> Key: LUCENE-8232
> URL: https://issues.apache.org/jira/browse/LUCENE-8232
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 7.4, master (8.0)
> Reporter: Simon Willnauer
> Priority: Major
> Fix For: 7.4, master (8.0)
>
> Attachments: LUCENE-8232.patch, LUCENE-8232.patch
>
>
> Today ReadersAndUpdates is tightly coupled with IW and all the handling of
> pending deletes. This change decouples IW and pending deletes from
> ReadersAndUpdates and allows expert users to customize how deletes are
> handled. This is useful or up to a certain extend mandatory to work with
> soft-deletes to allow merge policies to make the right decisions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
