SyncTransactionTableHandle
Defined in: packages/client/src/index.ts:1201
A table handle inside a SyncClient.transaction block (ADR-0022 §2). It collects mutations into the open write-unit rather than enqueuing each immediately; the whole set is enqueued atomically when the block’s callback returns. The calls are synchronous (collection only) — no per-call await needed.
Type Parameters
Section titled “Type Parameters”TRegistry
Section titled “TRegistry”TRegistry extends SyncTableRegistry
TKey extends SyncTableName<TRegistry>
Properties
Section titled “Properties”create
Section titled “create”create: (
input) =>void
Defined in: packages/client/src/index.ts:1205
Parameters
Section titled “Parameters”SyncTableCreateInput<TRegistry, TKey>
Returns
Section titled “Returns”void
delete
Section titled “delete”delete: (
entityKey) =>void
Defined in: packages/client/src/index.ts:1207
Parameters
Section titled “Parameters”entityKey
Section titled “entityKey”Record<string, string>
Returns
Section titled “Returns”void
update
Section titled “update”update: (
entityKey,patch) =>void
Defined in: packages/client/src/index.ts:1206
Parameters
Section titled “Parameters”entityKey
Section titled “entityKey”Record<string, string>
SyncTableUpdateInput<TRegistry, TKey>
Returns
Section titled “Returns”void
updateBlind
Section titled “updateBlind”updateBlind: (
entityKey,patch) =>void
Defined in: packages/client/src/index.ts:1225
An update-by-key with no local base row (ADR-0022 addendum). Ordinary update requires the entity
to be present in the actor’s local read model (it seeds the optimistic overlay and captures the base
server version); updateBlind skips that presence check and writes NO overlay — nothing appears in the
read model. Use it when the write target is deliberately EXCLUDED from your read shape (a write-only
flow, or an anonymity-scoped moderation write whose row streams only to a different projection), so there
is no local row to update and nothing to show optimistically.
Pessimistic-only. The /unit expander is authoritative for the outcome, so a blind write is meaningful
only inside a transaction({ mode: "pessimistic" }) block (or over a statically-pessimistic table). An
optimistic-routed blind write has nothing to converge and THROWS at enqueue.
The acked journal row retires without a synced echo (no visible row ever converges for it), so it does
not linger — unlike the seed-a-phantom-row workaround this replaces, whose acked row + overlay lingered
forever behind the echo barrier. A conflicted blind write stays dischargeable via discardConflict; a
rejected one is surfaced via onReject, both with no overlay to clean up.
Parameters
Section titled “Parameters”entityKey
Section titled “entityKey”Record<string, string>
SyncTableUpdateInput<TRegistry, TKey>
Returns
Section titled “Returns”void