chore: remove v2 models from schema #2107
Conversation
|
WalkthroughThis set of changes implements a comprehensive removal of numerous database tables, enums, and models related to integrations, jobs, triggers, endpoints, webhooks, and associated entities from the schema and database. The migration scripts sequentially drop dozens of tables and enum types, ensuring idempotency and cascading deletions where necessary. The Prisma schema is updated to reflect these removals, eliminating many models and relations. In their place, a simplified secret management system is introduced, adding new models for secret references and storage. Several existing models are also updated to remove now-obsolete fields and relations. No public or exported entities outside the schema are affected. 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (3)
💤 Files with no reviewable changes (3)
⏰ Context from checks skipped due to timeout of 90000ms (25)
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (8)
internal-packages/database/prisma/migrations/20250526095826_remove_v2_round_7/migration.sql (1)
1-7: Consider wrapping destructive DDL in a transaction
Explicitly enclosing theseDROP TABLEstatements inBEGIN; … COMMIT;can help ensure atomicity and rollback on error. Verify whether Prisma’s migration runner already provides this guarantee or add it here.internal-packages/database/prisma/migrations/20250526094442_remove_v2_round_3/migration.sql (1)
1-7: Consider wrapping destructive DDL in a transaction
Grouping these drops underBEGIN; … COMMIT;can improve safety by rolling back on failure. Confirm whether your migration runner already handles transactions.internal-packages/database/prisma/migrations/20250526095444_remove_v2_round_6/migration.sql (1)
1-10: Batch DDL operations: ensure atomicity
Dropping five tables in one go increases risk of a partial state on error. Wrap these operations in a transaction or split them into smaller chunks to guarantee rollback.internal-packages/database/prisma/migrations/20250526100059_remove_v2_round_8/migration.sql (1)
1-9: Consider wrapping destructive DDL in a transaction
A transactional wrapper (BEGIN; … COMMIT;) will help you avoid partial application if one drop fails. Validate your migration runner’s behavior.internal-packages/database/prisma/migrations/20250526092407_remove_v2_tables_round_1/migration.sql (1)
1-25: Enhance the data‐loss warning with recovery instructions
The block of warnings is useful, but consider adding brief guidance on backing up data or pointing to a runbook/rollback procedure for safer execution.internal-packages/database/prisma/schema.prisma (3)
330-333: DocumentSecretStoreProviderenum values
Consider adding comments above each provider (e.g.,DATABASE,AWS_PARAM_STORE) to clarify their intended usage and any configuration requirements.
335-343: Align naming conventions or add mapping directive
TheSecretStoremodel uses a camelCase name but defines a BTree index with raw ops. If your DB tables use snake_case, you might add an@@map("secret_store")or rename fields for consistency. This helps maintain uniform naming across Prisma and Postgres.
346-353: ExtendDataMigrationfor richer tracking
TheDataMigrationmodel has onlynameand timestamps. You may want to add a status enum (e.g.PENDING,COMPLETED,FAILED) or adetails Json?field for debugging and audit purposes.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
internal-packages/database/prisma/migrations/20250526092407_remove_v2_tables_round_1/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526093738_remove_v2_round_2/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526094044_remove_v2_trigger_http_endpoint_environment/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526094442_remove_v2_round_3/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526094729_remove_v2_round_4/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526095040_remove_v2_round_5/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526095444_remove_v2_round_6/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526095826_remove_v2_round_7/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526100059_remove_v2_round_8/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526100402_remove_v2_round_9/migration.sql(1 hunks)internal-packages/database/prisma/migrations/20250526100607_remove_v2_round_10/migration.sql(1 hunks)internal-packages/database/prisma/schema.prisma(1 hunks)
🔇 Additional comments (21)
internal-packages/database/prisma/migrations/20250526093738_remove_v2_round_2/migration.sql (1)
1-17: Approve removal of obsolete tables
This migration safely dropsJobRunExecution,ScheduleSource, andWebhookEnvironmentwithIF EXISTSandCASCADE, ensuring idempotency and automatic cleanup of dependent objects.internal-packages/database/prisma/migrations/20250526095040_remove_v2_round_5/migration.sql (1)
1-9: Approve dropping ofIntegrationConnection
UsingDROP TABLE IF EXISTS ... CASCADEmakes this migration safe to run repeatedly and automatically removes all dependencies.internal-packages/database/prisma/migrations/20250526094044_remove_v2_trigger_http_endpoint_environment/migration.sql (1)
1-13: Approve alteration and removal of trigger HTTP environment artifacts
The script cleanly drops thehttpEndpointEnvironmentIdcolumn and theTriggerHttpEndpointEnvironmenttable withIF EXISTSandCASCADE, preserving idempotency and cascading constraints.internal-packages/database/prisma/migrations/20250526094729_remove_v2_round_4/migration.sql (1)
1-14: Approve removal ofRunConnectionandTriggerSourcetables
This straightforward migration usesIF EXISTSandCASCADEfor safe, idempotent deletion of the two legacy tables and their dependencies.internal-packages/database/prisma/migrations/20250526100402_remove_v2_round_9/migration.sql (1)
1-21: Approve removal of legacy integration tables
DroppingExternalAccount,Integration,IntegrationAuthMethod, andIntegrationDefinitionwithIF EXISTS ... CASCADEensures the migration can be applied safely without leftover references.internal-packages/database/prisma/migrations/20250526095826_remove_v2_round_7/migration.sql (2)
9-9: Verify absence of dependencies onJobVersion
AlthoughCASCADEremoves dependent objects, ensure there are no critical views, functions, or application code still referencingJobVersionto avoid unintended side effects.
12-12: Verify absence of dependencies onTriggerHttpEndpoint
Similarly, confirm that no database objects (e.g., triggers, functions) or application modules reference this table before dropping it.internal-packages/database/prisma/migrations/20250526100607_remove_v2_round_10/migration.sql (1)
1-39: Ensure enum types aren’t still in use before dropping
If any table columns still reference these enums, the migration will fail. Consider running a check like:SELECT n.nspname AS schema, t.typname AS type, a.attrelid::regclass AS table, a.attname AS column FROM pg_type t JOIN pg_attribute a ON a.atttypid = t.oid JOIN pg_namespace n ON n.oid = t.typnamespace WHERE t.typname IN ( 'ConnectionType','DynamicTriggerType','IntegrationAuthSource', 'IntegrationSetupStatus','JobRunExecutionReason','JobRunExecutionStatus', 'JobRunStatus','JobStartPosition','JobVersionStatus','PayloadType', 'TaskChildExecutionMode','TaskStatus','TriggerChannel' );and migrate or drop those columns first.
internal-packages/database/prisma/migrations/20250526094442_remove_v2_round_3/migration.sql (2)
9-9: Confirm no residual dependencies onTask
Ensure no foreign keys, views, or functions reference theTasktable before dropping it; otherwise, migration may cascade unexpectedly.
12-12: Confirm no residual dependencies onWebhook
Similarly, verify that theWebhooktable is fully deprecated across code and schema to prevent surprises.internal-packages/database/prisma/migrations/20250526095444_remove_v2_round_6/migration.sql (5)
12-12: Verify no dependencies onDynamicTrigger
Check for lingering references (FKs, triggers, views) to avoid unexpected cascade deletions.
15-15: Verify no dependencies onEventDispatcher
Confirm that no database objects or code paths still rely on this table before dropping.
18-18: Verify no dependencies onEventRecord
Ensure deprecation across the codebase to prevent runtime errors post-migration.
21-21: Verify no dependencies onJobRun
Confirm safe removal—look for foreign keys and application logic references.
24-24: Verify no dependencies on_DynamicTriggerToJob
Double-check that this join table is no longer in use before dropping.internal-packages/database/prisma/migrations/20250526100059_remove_v2_round_8/migration.sql (4)
11-11: Verify no dependencies onConcurrencyLimitGroup
Ensure the table is fully deprecated in both schema and code to avoid unintended data loss.
14-14: Verify no dependencies onEndpoint
Confirm that no views, functions, or application modules still use this table.
17-17: Verify no dependencies onJob
Double-check that all references toJobhave been removed before dropping the table.
20-20: Verify no dependencies onJobQueue
Ensure this table is no longer in use in the code or other migrations.internal-packages/database/prisma/migrations/20250526092407_remove_v2_tables_round_1/migration.sql (2)
27-85:❓ Verification inconclusive
Verify foreign key dependencies and cascade settings
Currently onlyMissingConnectionis dropped withCASCADE. Confirm that none of the other tables have remaining foreign‐key constraints—otherwise theseDROP TABLEstatements may fail. You may want to either explicitly drop dependent constraints first or applyCASCADEwhere required.
🏁 Script executed:
#!/bin/bash # Verify no references to dropped tables in Prisma schema PRISMA_SCHEMA="internal-packages/database/prisma/schema.prisma" for tbl in JobCounter WebhookDeliveryCounter ApiIntegrationVote ConnectionAttempt DeferredScheduledEventService DynamicTriggerRegistration EndpointIndex EventExample HttpSourceRequestDelivery JobAlias JobIntegration JobRunAutoYieldExecution JobRunStatusRecord JobRunSubscription KeyValueItem TaskAttempt TriggerSourceOption WebhookRequestDelivery _JobRunToMissingConnection; do if rg -q "model ${tbl} " "$PRISMA_SCHEMA"; then echo "⚠️ Found lingering model $tbl in schema.prisma" fi doneLength of output: 8805
🏁 Script executed:
#!/bin/bash set -e MIGRATION_FILE="internal-packages/database/prisma/migrations/20250526092407_remove_v2_tables_round_1/migration.sql" echo "Checking for foreign key references to dropped tables" for tbl in JobCounter WebhookDeliveryCounter ApiIntegrationVote ConnectionAttempt DeferredScheduledEventService DynamicTriggerRegistration EndpointIndex EventExample HttpSourceRequestDelivery JobAlias JobIntegration JobRunAutoYieldExecution JobRunStatusRecord JobRunSubscription KeyValueItem TaskAttempt TriggerSourceOption WebhookRequestDelivery _JobRunToMissingConnection; do if rg -n "REFERENCES \"$tbl\"" "$MIGRATION_FILE"; then echo "⚠️ Found foreign key references to $tbl" fi done echo "Checking for explicit DROP CONSTRAINT statements" rg -n "DROP CONSTRAINT" "$MIGRATION_FILE"Length of output: 10298
No foreign‐key references or DROP CONSTRAINTs found in migration
We searched the SQL ininternal-packages/database/prisma/migrations/20250526092407_remove_v2_tables_round_1/migration.sqland found:
- No
REFERENCES "<TableName>"clauses for any of the tables being dropped- No explicit
DROP CONSTRAINTstatementsIt appears these tables have no inter-table foreign keys, so each
DROP TABLE IF EXISTSshould succeed as is. However, please manually confirm against your current database schema (or earlier migrations) that no remaining constraints reference these tables before deploying.
87-103:✅ Verification successful
Ensure enum types are no longer referenced anywhere
After dropping these enum types, verify that no columns in other tables still use them.
🏁 Script executed:
#!/bin/bash # Check for leftover enum references in Prisma schema PRISMA_SCHEMA="internal-packages/database/prisma/schema.prisma" for enum in EndpointIndexSource EndpointIndexStatus JobRunSubscriptionEvents JobRunSubscriptionRecipientMethod JobRunSubscriptionStatus TaskAttemptStatus; do if rg -q "${enum}" "$PRISMA_SCHEMA"; then echo "⚠️ Found lingering enum $enum in schema.prisma" fi doneLength of output: 1477
🏁 Script executed:
#!/bin/bash set -eo pipefail PRISMA_DIR="internal-packages/database/prisma" for enum in EndpointIndexSource \ EndpointIndexStatus \ JobRunSubscriptionEvents \ JobRunSubscriptionRecipientMethod \ JobRunSubscriptionStatus \ TaskAttemptStatus; do echo "Searching for references to $enum in $PRISMA_DIR..." if ! rg -n "$enum" "$PRISMA_DIR"; then echo " ✅ No references found for $enum" fi doneLength of output: 7041
✅ Prisma schema clean of removed enums
Ran a targeted search ininternal-packages/database/prisma/schema.prismafor all six dropped enum names; there are no lingering references. The only matches reside in historical migration files, which is expected. You can safely drop these enum types.
Removed v2 models from the schema in a safe way (migrations can be run manually on the database before actually applying the migrations during deploy). Takes the schema down from 22,268 tokens (93378 characters) to 14,317 tokens (59810 characters), a savings of 35.7%