[SERVER-64109] Evaluate design alternatives for sharing logic common to DeleteStage and BatchedDeleteStage Created: 02/Mar/22  Updated: 27/Oct/23  Resolved: 19/Apr/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Josef Ahmad Assignee: Josef Ahmad
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: Execution Team 2022-05-02
Participants:

 Description   

The BatchedDeleteStage class inherits from the DeleteStage class. Evaluate alternative this the inheritance scheme, like an abstracts delete stage the two classes independently implement, or sharing common logic in a separate module.



 Comments   
Comment by Josef Ahmad [ 19/Apr/22 ]

At this point, the design of the BatchedDeleteStage is pretty much consolidated. The code duplication with the legacy DeleteStage is negligible. The inheritance model has proved useful to maintain a common interface between the two stages, so that consumers can easily switch between the two delete stages. There's also an intention to make the BatchedDeleteStage the only delete stage in the long run. Based on all this, I don't think there's a need to explore alternatives to the design.

Generated at Thu Feb 08 05:59:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.