Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-49353

Refactor VectorClock's protected API

    • Fully Compatible
    • Sharding 2020-09-07

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

            Assignee:
            pierlauro.sciarelli@mongodb.com Pierlauro Sciarelli
            Reporter:
            kevin.pulo@mongodb.com Kevin Pulo
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: