atomicity-is-backend-independent

IN derived (depth 2)

Both storage backends enforce atomic isolated operations through backend-appropriate mechanisms: the SQLite backend uses context-managed load/save with write-flag gating and per-function transaction scope, while PostgreSQL uses per-method transactions with composite-key multi-tenancy — achieving the same transactional guarantee at different architectural levels

Summary

Both storage backends provide the same safety guarantee — mutations are atomic and isolated — but they achieve it through completely different architectural strategies. SQLite loads the full network into memory and protects it with context managers and write flags, while PostgreSQL skips the in-memory model entirely and runs each operation as its own SQL transaction with composite keys for tenant isolation. The practical upshot is that switching backends does not weaken transactional safety; the guarantees are equivalent even though the mechanisms have nothing in common.

Justifications

SL — Context-managed SQLite atomicity and per-method PostgreSQL transactions are backend-specific implementations of the same isolation guarantee

Antecedents (all must be IN):

  • api-layer-ensures-atomic-isolated-mutations — The API layer enforces mutation safety through four mechanisms: context-managed load/save, per-function transaction scope, write-flag gating to prevent unintended persistence, and dict-only returns that prevent callers from holding live network references.
  • pgapi-is-sql-native-multi-tenant — PgApi operates as a SQL-native multi-tenant implementation: all operations execute directly against PostgreSQL with no in-memory Network object constructed, composite primary keys on all tables provide project-level isolation, and each public method is a single committed transaction.

Dependents

These beliefs depend on this one:

Details