Commit Database¶
The Commit Database provides transactional persistence with history tracking.
CommitDatabase is the persistence layer; two stateless namespaces operate
over it, each taking a CommitDatabase as its first argument:
CommitStateBuilder— reconstruct aCommitStatefrom a chosen commit:state(db, id),initial_state(db).CommitDatabaseHelper— reduce heads and navigate:reduce_heads(db, anchor),forward/fast_forward.
(CommitDatabase itself answers topology queries — head_commit_ids,
last_commit_id, is_ancestor — and holds no “current” state.) A
CommitStore wraps the persistence layer and both namespaces behind a
stateful facade (undo/redo, the dispatch surface) for interactive apps. For
why a reconstructed state is a blind replay of the linearized trace, see
Commit Database.
Quick Start¶
from dsviper import CommitDatabase, CommitStateBuilder, CommitMutableState
# Open commit database (created with dsm_util.py)
db = CommitDatabase.open("model.cdb")
db.definitions().inject()
# Create mutable state from latest commit
state = CommitStateBuilder.state(db, db.last_commit_id())
mutable = CommitMutableState(state)
# Apply mutations via AttachmentMutating interface
mutating = mutable.attachment_mutating()
mutating.set(MYAPP_A_USER, key, document)
# Commit changes → returns new commit ID
commit_id = db.commit_mutations("Add user", mutable)
See also
For detailed examples and the Dual-Layer Contract, see Commit Database and The Dual-Layer Contract.
Path-Based Mutations¶
Use Path with update() to modify specific fields without replacing
the entire document. This enables disjoint concurrent writes — changes to
different fields converge automatically.
from dsviper import CommitDatabase, CommitStateBuilder, CommitMutableState, Path
db = CommitDatabase.open("model.cdb")
db.definitions().inject()
# Build a path to a nested field: document.address.city
path_city = Path.from_field("address").field("city").const()
# Create mutable state
state = CommitStateBuilder.state(db, db.last_commit_id())
mutable = CommitMutableState(state)
mutating = mutable.attachment_mutating()
# Update only the city field (not the whole document)
mutating.update(MYAPP_A_USER, user_key, path_city, "Paris")
# Commit
db.commit_mutations("Update city", mutable)
With set(), concurrent edits to the same document silently lose one (last-writer-wins). With update(),
edits to different fields converge without loss.
Supervised Reconciliation¶
Reconciling a merge — CommitMergeAnalyzer and friends — is an additive
supervisor over this API, documented on its own page:
Merge Reconciliation.
Database ↔ CommitDatabase Transfer¶
Moving content between the flat Database and the versioned
CommitDatabase — convert, materialize, faithful copy, and flatten — is a
set of converters documented on its own page: Database Transfer.
Choosing the Right Class¶
Use Case |
Class |
Example |
|---|---|---|
Open commit database |
|
|
Read state at specific commit |
|
|
Reduce divergent heads |
|
|
Prepare mutations |
|
|
Read documents (get, keys, has) |
|
|
Write documents (set, update) |
|
|
Inspect commit metadata |
|
|
Core Classes¶
A class used to represent a commit. |
|
A Commit database keeps the history of mutations in a DAG of commit. |
|
A low-level class used to represent the database based on SQLite3 through the CommitDatabasing interface. |
|
A low-level class used to represent a remote Commit database through the CommitDatabasing interface. |
|
A CommitDatabaseServer provide network access to a CommitDatabase. |
|
An interface used to abstract the implementation of the persistence layer for a Commit database. |
State Access¶
A class used to represent data at a specific commit. |
|
A class used to register the mutations of a value executed through the attachmentMutating interface. |
|
A utility class to build CommitState. |
History & DAG¶
A class used to represent a node in the commit DAG. |
|
A class used to represent the location of a commit node in the grid. |
|
A class used to build the grid layout of the commit DAG. |
|
A class used to represent the header of a commit. |
|
A class used to represent data associated with a commit during the synchronization of two databases. |
|
A class used by the evaluator to reconstruct a value by executing mutation opcodes. |
|
A utility class for a Commit Database. |
Synchronization¶
A high-level application class used to implement the store, dispatch, undo/redo and notification concepts inspired by the redux approach. |
|
An interface used to represent the notification emitted by a store. |
|
A class used to synchronize two concrete databases through the CommitDatabasing interface (low-level driver interface). |
|
A class used to represent data exchanged during the synchronization of two databases. |
|
A class used to represent statistics of data exchanged during the synchronization of two databases. |
|
A class used to represent data exchanged during the synchronization of two databases. |
Tracing¶
An interface used to trace a value (aka document). |
|
A class used to represent traced opcode. |
|
A class used to represent traced opcode. |
|
A class used to represent traced opcode. |
|
A class used to represent a traced opcode. |