dual-backend-atomicity-is-feature-complete

IN derived (depth 2)

Both storage backends provide atomic isolated operations with complete API coverage — the SQLite backend's context-managed mutations and PgApi's per-method transactions cover the same full set of operations

Summary

Both storage backends have reached full parity in how they protect data during writes. SQLite uses context-managed sessions that batch changes atomically, while PostgreSQL handles each operation as its own committed transaction — but both cover the entire API surface, so no operation is left unprotected regardless of which backend is in use.

Justifications

SL — Backend-independent atomicity achieves full feature parity only when PgApi implements the complete API surface

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.

Unless (any of these IN defeats this justification):

  • pgapi-partial-api-coverage — PgApi implements core operations (add/retract/assert/search/nogood/explain) but defers simulation, dialectics, namespace support, import/export, and maintenance operations to future work

Details