Commit System¶
The commit system provides transactional persistence with history tracking.
When to use: Use CommitDatabase for versioned persistence with history,
branching, and sync. Every change creates a commit, enabling undo/redo
and concurrent editing.
Quick Start¶
from dsviper import CommitDatabase, CommitMutableState
# Open versioned database (created with dsm_util.py)
db = CommitDatabase.open("model.cdb")
db.definitions().inject()
# Create mutable state from latest commit
state = db.state(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 System.
Path-Based Mutations¶
Use Path with update() to modify specific fields without replacing
the entire document. This enables multiplayer editing where concurrent
changes to different fields merge automatically.
from dsviper import CommitDatabase, 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 = db.state(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 cause one to be overwritten. With update(),
edits to different fields merge automatically—essential for multiplayer editing.
Choosing the Right Class¶
Use Case |
Class |
Example |
|---|---|---|
Open versioned database |
|
|
Read state at specific commit |
|
|
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. |
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. |
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. |