Add cascade delete on ProgramApplicationEvent enrollment relation#3917
Add cascade delete on ProgramApplicationEvent enrollment relation#3917devkiran wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
📝 WalkthroughWalkthroughThe PR modifies the Prisma schema to add cascade-on-delete behavior to the ChangesDatabase Schema Cascade Delete
Possibly Related PRs
Suggested Reviewers
Poem
🎯 1 (Trivial) | ⏱️ ~2 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/prisma/schema/application.prisma`:
- Line 61: The relation ProgramApplicationEvent -> programEnrollment currently
has onDelete: Cascade which will remove all ProgramApplicationEvent rows when a
ProgramEnrollment is deleted; to prevent loss of analytics, remove or change the
cascade to a safer behavior (e.g., onDelete: Restrict or onDelete: SetNull) on
the programEnrollment relation in application.prisma (affecting the
ProgramApplicationEvent model and the ProgramEnrollment relation), and if
cascade was intended only for tests, instead implement explicit test teardown or
a test-only schema; after changing the relation, generate and review the
corresponding migration so it reflects the non-destructive delete policy for
production.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 47652a4f-3848-4837-8b25-91337f041ab1
📒 Files selected for processing (1)
packages/prisma/schema/application.prisma
| referredByPartner Partner? @relation(fields: [referredByPartnerId], references: [id]) | ||
| application ProgramApplication? @relation(fields: [programApplicationId], references: [id]) | ||
| programEnrollment ProgramEnrollment? @relation(fields: [programId, partnerId], references: [programId, partnerId]) | ||
| programEnrollment ProgramEnrollment? @relation(fields: [programId, partnerId], references: [programId, partnerId], onDelete: Cascade) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for recent migration files related to this change
fd -e sql -t f . packages/prisma/migrations --exec ls -lt {} \; | head -20Repository: dubinc/dub
Length of output: 168
🏁 Script executed:
#!/bin/bash
# Check if ProgramApplicationEvent data is used for analytics/reporting
rg -n -C3 "ProgramApplicationEvent" --type=ts -g '!*.prisma' -g '!*test*' | head -50Repository: dubinc/dub
Length of output: 3669
🏁 Script executed:
# Verify the actual content of line 61 in the schema file
sed -n '55,65p' packages/prisma/schema/application.prismaRepository: dubinc/dub
Length of output: 558
🏁 Script executed:
# Find the correct location of migration files
find . -type d -name migrations | head -10Repository: dubinc/dub
Length of output: 84
🏁 Script executed:
# Check for migration files related to ProgramEnrollment or ProgramApplication
find . -name '*migration*' -type f | grep -i prisma | head -20Repository: dubinc/dub
Length of output: 36
🏁 Script executed:
# Verify the exact state of the programEnrollment relation
rg -A2 -B2 'programEnrollment.*`@relation`' packages/prisma/schema/Repository: dubinc/dub
Length of output: 7223
Verify that cascading deletion of event data is intentional and scoped appropriately.
Adding onDelete: Cascade to the programEnrollment relation will automatically delete all related ProgramApplicationEvent records when a ProgramEnrollment is deleted. This is problematic because ProgramApplicationEvent is actively used for production analytics and reporting (tracked in apps/web/app/(ee)/api/partners/applications/analytics/route.ts for submissions, approvals, and rejections metrics).
A few considerations:
-
Analytics impact: Deleting these events will affect historical reporting and analytics that depend on
ProgramApplicationEventdata. -
Codebase consistency: This pattern (
onDelete: CascadeonprogramEnrollmentrelations) is used elsewhere in the codebase (tag.prisma, network.prisma, fraud.prisma, bounty.prisma), suggesting it may be an accepted pattern. However, each should be evaluated based on the criticality of the data involved. -
Scope verification: Confirm whether this cascade behavior is intended for test cleanup only (e2e-cleanup PR context) or applies to production. If test-only, consider a separate schema or explicit test teardown logic.
Verify that the corresponding migration file aligns with these data retention requirements and that production analytics will not be affected.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@packages/prisma/schema/application.prisma` at line 61, The relation
ProgramApplicationEvent -> programEnrollment currently has onDelete: Cascade
which will remove all ProgramApplicationEvent rows when a ProgramEnrollment is
deleted; to prevent loss of analytics, remove or change the cascade to a safer
behavior (e.g., onDelete: Restrict or onDelete: SetNull) on the
programEnrollment relation in application.prisma (affecting the
ProgramApplicationEvent model and the ProgramEnrollment relation), and if
cascade was intended only for tests, instead implement explicit test teardown or
a test-only schema; after changing the relation, generate and review the
corresponding migration so it reflects the non-destructive delete policy for
production.
Summary by CodeRabbit