sneak/vaultik
1
0
Fork 0
Code Issues 7 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

schema: add ON DELETE CASCADE to snapshot_files.file_id and snapshot_blobs.blob_id FKs #46

Merged
sneak merged 1 commits from fix/issue-19-cascade-snapshot-fks into main 2026-03-19 14:03:40 +01:00
Conversation 3 Commits 1 Files Changed 1 +2 -2
clawbot commented 2026-03-17 21:42:30 +01:00
Collaborator
Copy Link

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

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
clawbot added 1 commit 2026-03-17 21:42:31 +01:00
schema: add ON DELETE CASCADE to snapshot_files.file_id and snapshot_blobs.blob_id FKs
All checks were successful
check / check (pull_request) Successful in 4m24s
Details
014e675dba 
closes #19
clawbot added the needs-review label 2026-03-17 21:42:43 +01:00
clawbot reviewed 2026-03-17 21:44:11 +01:00
clawbot left a comment
Author
Collaborator
Copy Link

REVIEW: PASS ✅

Reviewed PR #46 against issue #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.
clawbot added merge-ready and removed needs-review labels 2026-03-17 21:44:32 +01:00
sneak was assigned by clawbot 2026-03-17 21:44:32 +01:00
sneak commented 2026-03-19 13:59:54 +01:00
Owner
Copy Link

is this cascade delete in the right direction from table to table?

is this cascade delete in the right direction from table to table?
clawbot commented 2026-03-19 14:00:40 +01:00
Author
Collaborator
Copy Link

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 main 2026-03-19 14:03:40 +01:00
sneak deleted branch fix/issue-19-cascade-snapshot-fks 2026-03-19 14:03:40 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
clawbot
Labels
Clear labels
merge-ready
All checks pass, reviewed, rebased, ready for merge
 needs-checks
make check does not pass cleanly
 needs-rebase
PR has merge conflicts or is behind main
 needs-review
Code review not yet done
 needs-review
needs-review
needs-review
needs-review
needs-rework
Code review found issues to fix
No Label merge-ready
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
clawbot sneak
No Assignees sneak
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/vaultik#46
Delete Branch "fix/issue-19-cascade-snapshot-fks"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?