Module db

Database keys used by the client

Structs

• ApiSecretKey
• ApiSecretKeyPrefix
• CachedApiVersionSet
• CachedApiVersionSetKey
• ChronologicalOperationLogKey
  Key used to lookup operation log entries in chronological order
• ChronologicalOperationLogKeyPrefix
• ClientConfigKey
• ClientConfigKeyPrefixV0
• ClientConfigKeyV0
• ClientInitStateKey
  Does the client modules need to run recovery before being usable?
• ClientInitStatePrefix
• ClientMetadataKey
  Client metadata that will be stored/restored on backup&recovery
• ClientMetadataPrefix
• ClientModuleRecovery
• ClientModuleRecoveryPrefix
• ClientModuleRecoveryState
• ClientPreRootSecretHashKey
• ClientRecoverySnapshot
• ClientRecoverySnapshotPrefix
• DbKeyPrefixIter
  An iterator over the variants of DbKeyPrefix
• EncodedClientSecretKey
• EncodedClientSecretKeyPrefix
• LastBackupKey
  Last valid backup the client attempted to make
• MetaFieldKey
• MetaFieldPrefix
• MetaFieldValue
• MetaServiceInfo
• MetaServiceInfoKey
• OperationLogKey
• OperationLogKeyPrefix
• PeerLastApiVersionsSummary
• PeerLastApiVersionsSummaryKey

Enums

• DbKeyPrefix
• InitMode
  Client initialization mode
• InitModeComplete
  Like InitMode, but without no longer required data.
• InitState
  The state of the client initialization

Functions

• apply_migrations_client
  apply_migrations_client iterates from the on disk database version for the client module up to target_db_version and executes all of the migrations that exist in the migrations map, including state machine migrations. Each migration in the migrations map updates the database to have the correct on-disk data structures that the code is expecting. The entire process is atomic, (i.e migration from 0->1 and 1->2 happen atomically). This function is called before the module is initialized and as long as the correct migrations are supplied in the migrations map, the module will be able to read and write from the database successfully.
• apply_migrations_core_client
• get_active_states
  Reads all active states from the database and returns Vec<DynState>. TODO: It is unfortunate that we can’t read states by the module’s instance id so we are forced to return all active states. Once we do a db migration to add module_instance_id to ActiveStateKey, this can be improved to only read the module’s relevant states.
• get_core_client_database_migrations
• get_inactive_states
  Reads all inactive states from the database and returns Vec<DynState>. TODO: It is unfortunate that we can’t read states by the module’s instance id so we are forced to return all inactive states. Once we do a db migration to add module_instance_id to InactiveStateKey, this can be improved to only read the module’s relevant states.
• migrate_state
  Migrates a particular state by looping over all active and inactive states. If the migrate closure returns None, this state was not migrated and should be added to the new state machine vectors.
• remove_old_and_persist_new_active_states
  Persists new active states by first removing all current active states, and re-writing with the new set of active states. new_active_states is expected to contain all active states, not just the newly created states.
• remove_old_and_persist_new_inactive_states
  Persists new inactive states by first removing all current inactive states, and re-writing with the new set of inactive states. new_inactive_states is expected to contain all inactive states, not just the newly created states.

Type Aliases

• ClientMigrationFn
  ClientMigrationFn is a function that modules can implement to “migrate” the database to the next database version.
• MigrateStateFn 🔒
  Helper function definition for migrating a single state.