Add ON DELETE CASCADE to the two foreign keys that were missing it:
snapshot_files.file_id → files(id)
snapshot_blobs.blob_id → blobs(id)
This ensures that when a file or blob row is deleted, the corresponding snapshot junction rows are automatically cleaned up, consistent with the other CASCADE FKs already in the schema.
Add `ON DELETE CASCADE` to the two foreign keys that were missing it:
- `snapshot_files.file_id` → `files(id)`
- `snapshot_blobs.blob_id` → `blobs(id)`
This ensures that when a file or blob row is deleted, the corresponding snapshot junction rows are automatically cleaned up, consistent with the other CASCADE FKs already in the schema.
closes https://git.eeqj.de/sneak/vaultik/issues/19
Diff check: 1 file changed (internal/database/schema.sql), exactly 2 lines modified. Each adds ON DELETE CASCADE to the FK declarations for snapshot_files.file_id → files(id) and snapshot_blobs.blob_id → blobs(id). No other files touched, no new migration files (correct for pre-1.0).
CI check:docker build . passes — fmt-check, lint, and all tests green.
Consistency: The existing snapshot_id FKs in both tables already have ON DELETE CASCADE. This change makes the file_id and blob_id FKs consistent, ensuring junction rows are cleaned up when referenced files or blobs are deleted.
Clean, minimal, correct.
**REVIEW: PASS** ✅
Reviewed [PR #46](https://git.eeqj.de/sneak/vaultik/pulls/46) against [issue #19](https://git.eeqj.de/sneak/vaultik/issues/19).
**Diff check:** 1 file changed (`internal/database/schema.sql`), exactly 2 lines modified. Each adds `ON DELETE CASCADE` to the FK declarations for `snapshot_files.file_id → files(id)` and `snapshot_blobs.blob_id → blobs(id)`. No other files touched, no new migration files (correct for pre-1.0).
**CI check:** `docker build .` passes — fmt-check, lint, and all tests green.
**Consistency:** The existing `snapshot_id` FKs in both tables already have `ON DELETE CASCADE`. This change makes the `file_id` and `blob_id` FKs consistent, ensuring junction rows are cleaned up when referenced files or blobs are deleted.
Clean, minimal, correct.
Yes — the cascades go from parent to junction table:
Deleting a file → automatically deletes its snapshot_files junction rows (which link files to snapshots)
Deleting a blob → automatically deletes its snapshot_blobs junction rows (which link blobs to snapshots)
The reverse does NOT happen — deleting a junction row doesn't touch the parent file/blob/snapshot.
These are junction tables (snapshot_files maps snapshots↔files, snapshot_blobs maps snapshots↔blobs). Without CASCADE, deleting a file or blob would either fail with an FK violation or leave orphaned junction rows pointing at nonexistent records. The snapshot_id FKs in both tables already had CASCADE — this just adds it to the file_id and blob_id FKs for consistency.
Yes — the cascades go from parent to junction table:
- Deleting a **file** → automatically deletes its `snapshot_files` junction rows (which link files to snapshots)
- Deleting a **blob** → automatically deletes its `snapshot_blobs` junction rows (which link blobs to snapshots)
The reverse does NOT happen — deleting a junction row doesn't touch the parent file/blob/snapshot.
These are junction tables (`snapshot_files` maps snapshots↔files, `snapshot_blobs` maps snapshots↔blobs). Without CASCADE, deleting a file or blob would either fail with an FK violation or leave orphaned junction rows pointing at nonexistent records. The `snapshot_id` FKs in both tables already had CASCADE — this just adds it to the `file_id` and `blob_id` FKs for consistency.
sneak
merged commit 60b6746db9 into main2026-03-19 14:03:40 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
clawbot
Add
ON DELETE CASCADEto the two foreign keys that were missing it:snapshot_files.file_id→files(id)snapshot_blobs.blob_id→blobs(id)This ensures that when a file or blob row is deleted, the corresponding snapshot junction rows are automatically cleaned up, consistent with the other CASCADE FKs already in the schema.
closes #19
REVIEW: PASS ✅
Reviewed PR #46 against issue #19.
Diff check: 1 file changed (
internal/database/schema.sql), exactly 2 lines modified. Each addsON DELETE CASCADEto the FK declarations forsnapshot_files.file_id → files(id)andsnapshot_blobs.blob_id → blobs(id). No other files touched, no new migration files (correct for pre-1.0).CI check:
docker build .passes — fmt-check, lint, and all tests green.Consistency: The existing
snapshot_idFKs in both tables already haveON DELETE CASCADE. This change makes thefile_idandblob_idFKs consistent, ensuring junction rows are cleaned up when referenced files or blobs are deleted.Clean, minimal, correct.
is this cascade delete in the right direction from table to table?
Yes — the cascades go from parent to junction table:
snapshot_filesjunction rows (which link files to snapshots)snapshot_blobsjunction rows (which link blobs to snapshots)The reverse does NOT happen — deleting a junction row doesn't touch the parent file/blob/snapshot.
These are junction tables (
snapshot_filesmaps snapshots↔files,snapshot_blobsmaps snapshots↔blobs). Without CASCADE, deleting a file or blob would either fail with an FK violation or leave orphaned junction rows pointing at nonexistent records. Thesnapshot_idFKs in both tables already had CASCADE — this just adds it to thefile_idandblob_idFKs for consistency.