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

OperationLogEntryV0

V0 version of operation log entry for migration purposes

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_module

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_client_module_dbtx

apply_migrations_core_client_dbtx

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_decoded_client_secret

Fetches the encoded client secret from the database and decodes it. If an encoded client secret is not present in the database, or if decoding fails, an error is returned.

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.

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.

verify_client_db_integrity_dbtx 🔒