The ragtime DataStore half of Syncopate.
Applied-migration state lives in a dedicated key-value DBI on the same
environment the app's Datalog connection already holds — never as datoms. This
holds for both connection kinds, via datalevin's datalog-kv:
datalog-kv returns the connection's
own LMDB handle.dtlv:// URI): datalog-kv returns a KV view that
shares the remote Datalog store's clients and transaction. The applied-id DBI
sits on the SAME server database (alongside datalevin/eav etc.), and a write
on a transaction-bound connection joins the migration's with-transaction. No
separate KV session is opened, so embedded and client/server fold identically.The ragtime DataStore half of Syncopate. Applied-migration state lives in a dedicated key-value DBI on the *same* environment the app's Datalog connection already holds — never as datoms. This holds for both connection kinds, via datalevin's `datalog-kv`: - **embedded** (a local LMDB directory): `datalog-kv` returns the connection's own LMDB handle. - **client/server** (a `dtlv://` URI): `datalog-kv` returns a KV *view* that shares the remote Datalog store's clients and transaction. The applied-id DBI sits on the SAME server database (alongside `datalevin/eav` etc.), and a write on a transaction-bound connection joins the migration's `with-transaction`. No separate KV session is opened, so embedded and client/server fold identically.
(close! _store)Release resources the store holds beyond its conn. The applied-migration KV
handle shares the connection's own environment (embedded) or its server clients
(client/server), so there is nothing extra to release. This is a no-op kept for
API symmetry; the caller closes the connection.
Release resources the store holds beyond its `conn`. The applied-migration KV handle shares the connection's own environment (embedded) or its server clients (client/server), so there is nothing extra to release. This is a no-op kept for API symmetry; the caller closes the connection.
(conn->kv conn)The KV handle backing a Datalog connection, via datalevin's datalog-kv. Works
embedded and client/server, and on a transaction-bound connection, so the atomic
helpers in syncopate.core can write the applied-id inside the migration's own
with-transaction. On client/server it is a KV view sharing the connection's
clients and transaction, not a separate session.
The KV handle backing a Datalog connection, via datalevin's `datalog-kv`. Works embedded and client/server, and on a transaction-bound connection, so the atomic helpers in `syncopate.core` can write the applied-id inside the migration's own `with-transaction`. On client/server it is a KV view sharing the connection's clients and transaction, not a separate session.
(ensure-store! kv dbi-name)Open (creating if absent) the migrations DBI on kv. Idempotent — our
equivalent of the SQL adaptors' ensure-migrations-table-exists.
Open (creating if absent) the migrations DBI on `kv`. Idempotent — our equivalent of the SQL adaptors' `ensure-migrations-table-exists`.
(next-seq kv dbi-name)The next monotonic application sequence number for the migrations DBI on kv:
one past the largest :seq on record (never reused, so it's robust to the gaps
unrecord! leaves). Ordering by :seq reflects true application order, immune to
wall-clock millisecond ties.
The next monotonic application sequence number for the migrations DBI on `kv`: one past the largest `:seq` on record (never reused, so it's robust to the gaps `unrecord!` leaves). Ordering by `:seq` reflects true application order, immune to wall-clock millisecond ties.
(record! kv dbi-name id seq)Record id as applied with application sequence seq on kv (which may be a
transaction-bound handle). Assumes the DBI already exists (see ensure-store!).
Record `id` as applied with application sequence `seq` on `kv` (which may be a transaction-bound handle). Assumes the DBI already exists (see `ensure-store!`).
(store conn)(store conn {:keys [dbi-name] :or {dbi-name default-dbi-name}})Construct a Syncopate DataStore over a live Datalevin connection — embedded or
client/server (dtlv://). The applied-migration DBI lives on the connection's
own environment (embedded) or the same server database (client/server), reached
via datalog-kv.
Options: :dbi-name - name of the KV DBI holding applied-migration state (default "__syncopate_migrations").
Construct a Syncopate DataStore over a live Datalevin connection — embedded or
client/server (`dtlv://`). The applied-migration DBI lives on the connection's
own environment (embedded) or the same server database (client/server), reached
via `datalog-kv`.
Options:
:dbi-name - name of the KV DBI holding applied-migration state
(default "__syncopate_migrations").(unrecord! kv dbi-name id)Remove id from the applied set on kv (which may be transaction-bound).
Remove `id` from the applied set on `kv` (which may be transaction-bound).
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |