Joseph Doherty
26 lines
1.6 KiB
SQL
26 lines
1.6 KiB
SQL
-- 0014_phase45_schema.sql — Phase 4.5 Wave 2 schema bump (T109).
|
|
--
|
|
-- Two schema concerns are bundled into this migration:
|
|
--
|
|
-- 1. ``embeddings.memory_id`` FK should ideally carry ``ON DELETE CASCADE``
|
|
-- (T88 review nit). DEFERRED to Phase 5: ``embeddings`` rows are only ever
|
|
-- deleted when the parent ``memories`` row is deleted, and ``memories``
|
|
-- rows are never deleted today (memory hide is a soft flag; the surgical
|
|
-- ``deindex_event`` path operates on ``event_log`` and does NOT cascade
|
|
-- to projection rows). The CASCADE constraint therefore can't fire under
|
|
-- current usage — adding the SQLite table-rebuild dance (rename, recreate,
|
|
-- copy, drop, reindex) for a defensive constraint is unwarranted bloat
|
|
-- in a polish wave. Revisit during the broader Phase 5 migration cleanup
|
|
-- when other table reshapes make the rebuild worthwhile.
|
|
--
|
|
-- 2. Add ``memories.event_id`` (NULLABLE INTEGER, references ``event_log.id``)
|
|
-- so cross-chat search results can deep-link back to the originating
|
|
-- turn (foundation for T111). The column is nullable so historical
|
|
-- memory rows projected before 0014 ran continue to round-trip cleanly;
|
|
-- new rows are populated by the ``memory_written`` projector handler
|
|
-- from the projecting event's id. This is a pure additive change — no
|
|
-- backfill is performed. Older rows simply read NULL until/unless a
|
|
-- later migration backfills them; T111 surfaces are coded to accept
|
|
-- NULL gracefully (no deep-link rendered).
|
|
ALTER TABLE memories ADD COLUMN event_id INTEGER REFERENCES event_log(id);
|