[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. |