The uploads table's foreign key on snapshot_id did not cascade deletes, unlike snapshot_files and snapshot_blobs. This caused FK violations when deleting snapshots with associated upload records (if FK enforcement is enabled) unless uploads were manually deleted first.
Adds ON DELETE CASCADE to the snapshot_id FK in schema.sql for consistency with the other snapshot-referencing tables.
docker build . passes (fmt-check, lint, all tests, build).
The `uploads` table's foreign key on `snapshot_id` did not cascade deletes, unlike `snapshot_files` and `snapshot_blobs`. This caused FK violations when deleting snapshots with associated upload records (if FK enforcement is enabled) unless uploads were manually deleted first.
Adds `ON DELETE CASCADE` to the `snapshot_id` FK in `schema.sql` for consistency with the other snapshot-referencing tables.
`docker build .` passes (fmt-check, lint, all tests, build).
closes https://git.eeqj.de/sneak/vaultik/issues/18
The uploads table's foreign key on snapshot_id did not cascade deletes,
unlike snapshot_files and snapshot_blobs. This caused FK violations when
deleting snapshots with associated upload records (if FK enforcement is
enabled) unless uploads were manually deleted first.
closes #18
PR #44 adds ON DELETE CASCADE to the uploads table's snapshot_id foreign key in internal/database/schema.sql, fixing issue #18.
Checks
✅Diff: Single file, single line — FOREIGN KEY (snapshot_id) REFERENCES snapshots(id) → FOREIGN KEY (snapshot_id) REFERENCES snapshots(id) ON DELETE CASCADE
✅Consistency: All other snapshot-referencing FKs (snapshot_files line 105, snapshot_blobs line 118) already have ON DELETE CASCADE. The uploads table now matches.
✅No new migration files: Schema edited in-place in schema.sql, correct for pre-1.0.0 per REPO_POLICIES.
✅docker build .: Passes (fmt-check, lint, tests, build all green).
✅Commit hygiene: Single commit, clear message (fix: add ON DELETE CASCADE to uploads FK on snapshot_id).
## Review: **PASS** ✅
### What was reviewed
[PR #44](https://git.eeqj.de/sneak/vaultik/pulls/44) adds `ON DELETE CASCADE` to the `uploads` table's `snapshot_id` foreign key in `internal/database/schema.sql`, fixing [issue #18](https://git.eeqj.de/sneak/vaultik/issues/18).
### Checks
- ✅ **Diff**: Single file, single line — `FOREIGN KEY (snapshot_id) REFERENCES snapshots(id)` → `FOREIGN KEY (snapshot_id) REFERENCES snapshots(id) ON DELETE CASCADE`
- ✅ **Consistency**: All other snapshot-referencing FKs (`snapshot_files` line 105, `snapshot_blobs` line 118) already have `ON DELETE CASCADE`. The `uploads` table now matches.
- ✅ **No new migration files**: Schema edited in-place in `schema.sql`, correct for pre-1.0.0 per REPO_POLICIES.
- ✅ **`docker build .`**: Passes (fmt-check, lint, tests, build all green).
- ✅ **Commit hygiene**: Single commit, clear message (`fix: add ON DELETE CASCADE to uploads FK on snapshot_id`).
- ✅ **PR links issue**: `closes https://git.eeqj.de/sneak/vaultik/issues/18`
Nothing wrong. Ship it.
It's the other direction — we don't. The ON DELETE CASCADE is on the FK from uploads.snapshot_id → snapshots.id, so:
Deleting a snapshot → automatically deletes its upload records✅
Deleting an upload record → does NOT touch the snapshot
Without the cascade, deleting a snapshot with associated upload records would either fail with an FK violation (if enforcement is on) or leave orphaned upload rows pointing at a nonexistent snapshot. The other two snapshot-referencing tables (snapshot_files, snapshot_blobs) already had ON DELETE CASCADE — this just brings uploads in line.
It's the other direction — we don't. The `ON DELETE CASCADE` is on the FK from `uploads.snapshot_id` → `snapshots.id`, so:
- Deleting a **snapshot** → automatically deletes its **upload records** ✅
- Deleting an **upload record** → does NOT touch the snapshot
Without the cascade, deleting a snapshot with associated upload records would either fail with an FK violation (if enforcement is on) or leave orphaned upload rows pointing at a nonexistent snapshot. The other two snapshot-referencing tables (`snapshot_files`, `snapshot_blobs`) already had `ON DELETE CASCADE` — this just brings `uploads` in line.
sneak
merged commit f28c8a73b7 into main2026-03-19 13:59:27 +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.
The
uploadstable's foreign key onsnapshot_iddid not cascade deletes, unlikesnapshot_filesandsnapshot_blobs. This caused FK violations when deleting snapshots with associated upload records (if FK enforcement is enabled) unless uploads were manually deleted first.Adds
ON DELETE CASCADEto thesnapshot_idFK inschema.sqlfor consistency with the other snapshot-referencing tables.docker build .passes (fmt-check, lint, all tests, build).closes #18
Review: PASS ✅
What was reviewed
PR #44 adds
ON DELETE CASCADEto theuploadstable'ssnapshot_idforeign key ininternal/database/schema.sql, fixing issue #18.Checks
FOREIGN KEY (snapshot_id) REFERENCES snapshots(id)→FOREIGN KEY (snapshot_id) REFERENCES snapshots(id) ON DELETE CASCADEsnapshot_filesline 105,snapshot_blobsline 118) already haveON DELETE CASCADE. Theuploadstable now matches.schema.sql, correct for pre-1.0.0 per REPO_POLICIES.docker build .: Passes (fmt-check, lint, tests, build all green).fix: add ON DELETE CASCADE to uploads FK on snapshot_id).closes https://git.eeqj.de/sneak/vaultik/issues/18Nothing wrong. Ship it.
why do we want to delete snapshots when deleting upload records?
It's the other direction — we don't. The
ON DELETE CASCADEis on the FK fromuploads.snapshot_id→snapshots.id, so:Without the cascade, deleting a snapshot with associated upload records would either fail with an FK violation (if enforcement is on) or leave orphaned upload rows pointing at a nonexistent snapshot. The other two snapshot-referencing tables (
snapshot_files,snapshot_blobs) already hadON DELETE CASCADE— this just bringsuploadsin line.