[SERVER-49353] Refactor VectorClock's protected API Created: 08/Jul/20  Updated: 29/Oct/23  Resolved: 27/Aug/20

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

Type: Improvement Priority: Major - P3
Reporter: Kevin Pulo Assignee: Pierlauro Sciarelli
Resolution: Fixed Votes: 0
Labels: PM-1645-Milestone-3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Backwards Compatibility: Fully Compatible
Sprint: Sharding 2020-09-07
Participants:

 Description   

Currently VectorClock/VectorClockMutable provide pure virtual methods that are implemented in concrete classes by calling back into VectorClock/VectorClockMutable methods for the necessary Components. (eg. gossipOut calls one of gossipOutInternal or gossipOutExternal, which is implemented in the concrete classes by calling _gossipOutComponent). This provides a lot of flexibility that isn't really needed, at the cost of a confusing call chain and overly excessive use of protected methods.

Better would be for the pure virtual methods to return an indication of which Components should be gossiped/ticked/persisted, with the base class then doing the appropriate operations on those Components. This will allow _gossipOutComponent et al to be private, rather than protected. The obvious choices for how the concrete classes should indicate which Components are relevant are std::vector<Component> or ComponentArray<bool>.



 Comments   
Comment by Githook User [ 27/Aug/20 ]

Author:

{'name': 'Pierlauro Sciarelli', 'email': 'pierlauro.sciarelli@mongodb.com', 'username': 'pierlauro'}

Message: SERVER-49353 Refactor VectorClock's protected API
Branch: master
https://github.com/mongodb/mongo/commit/1d3972cea1ae1a35e398fe61882cd455d78c01d1

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