-
released this
2026-06-09 19:04:45 +02:00 | 305 commits to main since this releaseHighlights
Per-entity optimistic concurrency, the read-then-CAS lock pattern, and idempotent-bootstrap singleton inserts.
entity._rev: number— monotonic per-entity counter, auto-bumped on everyupdate(). Surfaced onget()/find()/search(). Pre-7.31.0 entities read as_rev: 1.update({ ifRev: N })— CAS check. ThrowsRevisionConflictErrorcarrying{ id, expected, actual }if the persisted_revno longer matches.add({ ifAbsent: true })+addMany({ items, ifAbsent: true })— by-ID idempotent insert. Returns the existingidif present, no throw, no overwrite.RevisionConflictErrorexported from the public API.
The full optimistic-concurrency guide walks through the lock pattern, read-modify-write retry, idempotent bootstrap, and how
_revinteracts with branches, snapshots, and VFS file versioning.Why this scope (and why no
brain.transaction())A public transaction wrapper was on the table but was cut. The internal
TransactionManagerexposes rawOperationclasses that take aStorageAdapterconstructor arg; a clean high-level facade in 7.31.0 was either (a) "delegate tobrain.add()/update()/relate()" which each commit their own internal transaction before the closure returns (looks atomic, isn't), or (b) threadtx?through every internal write site (~2 days + regression surface). The SDK-scheduler use case driving this is the read-then-CAS lock pattern, fully solved by_rev+ifRev. Multi-write atomicity lands in 8.0's Datomic-stylebrain.transact()where it's atomic by construction.Cortex compatibility
Zero changes required.
_revis a single integer field updated alongside every other metadata field; Cortex never sees the per-entity counter.Tests
- New
tests/integration/rev-and-ifabsent.test.ts(18 tests) - 1468 / 1468 unit suite passing
See RELEASES.md for the full entry.
Downloads
-
Source code (ZIP)
0 downloads
-
Source code (TAR.GZ)
0 downloads