fix: add ON DELETE CASCADE to uploads FK on snapshot_id #44

clawbot · 2026-03-17T13:48:49+01:00

clawbot commented

2026-03-17 13:48:49 +01:00

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 #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. 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

clawbot added 1 commit 2026-03-17 13:48:50 +01:00

fix: add ON DELETE CASCADE to uploads FK on snapshot_id

check / check (pull_request) Successful in 4m15s

Details

bc70a0a973

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

clawbot added the needs-review label 2026-03-17 13:49:55 +01:00

clawbot commented

2026-03-17 13:55:49 +01:00

Review: PASS ✅

What was reviewed

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).
✅ PR links issue: closes https://git.eeqj.de/sneak/vaultik/issues/18

Nothing wrong. Ship it.

## 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.

clawbot added merge-ready and removed needs-review labels 2026-03-17 21:37:29 +01:00

sneak was assigned by clawbot

2026-03-17 21:37:29 +01:00

sneak commented

2026-03-19 00:24:52 +01:00

why do we want to delete snapshots when deleting upload records?

clawbot commented

2026-03-19 00:25:21 +01:00

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 main

2026-03-19 13:59:27 +01:00

sneak deleted branch fix/uploads-fk-cascade

2026-03-19 13:59:27 +01:00

sneak referenced this issue from a commit

2026-03-19 13:59:29 +01:00

fix: add ON DELETE CASCADE to uploads FK on snapshot_id (#44)

clawbot referenced this pull request

2026-03-19 14:05:18 +01:00

fix: use deleteSnapshotFromLocalDB in syncWithRemote #47

clawbot referenced this pull request

2026-03-20 06:57:51 +01:00