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

OperationLogKeyPrefixV0

OperationLogKeyV0

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.