forked from bitcoin/bitcoin
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
refactor: decouple db hooks from CFlatDB-based C*Manager objects, mig…
…rate to *Store structs (#5555) ## Motivation As highlighted in dashpay/dash-issues#52, decoupling of `CFlatDB`-interacting components from managers of objects like `CGovernanceManager` and `CSporkManager` is a key task for achieving deglobalization of Dash-specific components. The design of `CFlatDB` as a flat database agent relies on hooking into the object's state its meant to load and store, using its (de)serialization routines and other miscellaneous functions (notably, without defining an interface) to achieve those ends. This approach was taken predominantly for components that want a single-file cache. Because of the method it uses to hook into the object (templates and the use of temporary objects), it explicitly prevented passing arguments into the object constructor, an explicit requirement for storing references to other components during construction. This, in turn, created an explicit dependency on those same components being available in the global context, which would block the backport of bitcoin#21866, a requirement for future backports meant to achieve parity in `assumeutxo` support. The design of these objects made no separation between persistent (i.e. cached) and ephemeral (i.e. generated/fetched during initialization or state transitions) data and the design of `CFlatDB` attempts to "clean" the database by breaching this separation and attempting to access this ephemeral data. This might be acceptable if it is contained within the manager itself, like `CSporkManager`'s `CheckAndRemove()` but is utterly unacceptable when it relies on other managers (that, as a reminder, are only accessible through the global state because of restrictions caused by existing design), like `CGovernanceManager`'s `UpdateCachesAndClean()`. This pull request aims to separate the `CFlatDB`-interacting portions of these managers into a struct, with `CFlatDB` interacting only with this struct, while the manager inherits the struct and manages load/store/update of the database through the `CFlatDB` instance initialized within its scope, though the instance only has knowledge of what is exposed through the limited parent struct. ## Additional information * As regards to existing behaviour, `CFlatDB` is written entirely as a header as it relies on templates to specialize itself for the object it hooks into. Attempting to split the logic and function definitions into separate files will require you to explicitly define template specializations, which is tedious. * `m_db` is defined as a pointer as you cannot instantiate a forward-declared template (see [this Stack Overflow answer](https://stackoverflow.com/a/12797282) for more information), which is done when defined as a member in the object scope. * The conditional cache flush predicating on RPC _not_ being in the warm-up state has been replaced with unconditional flushing of the database on object destruction (@UdjinM6, is this acceptable?) ## TODOs This is a list of things that aren't within the scope of this pull request but should be addressed in subsequent pull requests * [ ] Definition of an interface that `CFlatDB` stores are expected to implement * [ ] Lock annotations for all potential uses of members protected by the `cs` mutex in each manager object and store * [ ] Additional comments documenting what each function and member does * [ ] Deglobalization of affected managers --------- Co-authored-by: Kittywhiskers Van Gogh <[email protected]>
- Loading branch information
Showing
21 changed files
with
440 additions
and
334 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.