chore: update migrations - #1170
Conversation
WalkthroughDatabase schema migration introducing constraint naming standardization and snapshot format upgrade from version 7 to version 8. Constraint names across five tables converted to snake_case convention. Migration snapshots restructured from nested per-table definitions to a flattened DDL-based array model with normalized entity types. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Possibly related PRs
Suggested reviewers
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✨ 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 |
![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 (4)
packages/db/migrations/meta/1747760252_snapshot.json (1)
167-181: Same note: prefer timestamptz/jsonb in new changes.Keep as-is for historical snapshots; adopt timestamptz/jsonb in new migrations to reduce future drift.
Also applies to: 359-370, 599-610
packages/db/migrations/meta/1747927048_snapshot.json (1)
599-610: Same non-blocker: consider jsonb/timestamptz in future migrations.Applies repo-wide; no change requested here.
Also applies to: 1503-1517
packages/db/migrations/meta/1748033482_snapshot.json (1)
115-126: Prefer jsonb and timestamptz in future migrations; existing snapshots are auto-generated.Verification confirms json and timestamp types exist throughout migration snapshots (lines 115–126, 183–197, 612–623 all verified in 1748033482_snapshot.json). For future work: PostgreSQL does favor "jsonb" over "json" for better indexing and query performance, and "timestamptz" over "timestamp" for timezone correctness. Since these snapshots are auto-generated by your schema migration tool, standardize the preference at the ORM configuration level rather than manually refactoring existing records.
packages/db/migrations/meta/_journal.json (1)
2-3: Update journal header to align with snapshot versions (v8/postgres).All 65 snapshots in the migration metadata are version 8 with PostgreSQL dialect, but the journal header remains version 7 with legacy "postgresql" dialect. This inconsistency should be corrected to prevent tool confusion.
- "version": "7", - "dialect": "postgresql", + "version": "8", + "dialect": "postgres",
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
packages/db/migrations/1763457421_smiling_elektra.sql(1 hunks)packages/db/migrations/meta/1747760252_snapshot.json(1 hunks)packages/db/migrations/meta/1747915707_snapshot.json(1 hunks)packages/db/migrations/meta/1747927048_snapshot.json(1 hunks)packages/db/migrations/meta/1747930278_snapshot.json(1 hunks)packages/db/migrations/meta/1748033482_snapshot.json(1 hunks)packages/db/migrations/meta/_journal.json(1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: generate / run
- GitHub Check: test / run
- GitHub Check: build / run
- GitHub Check: lint / run
- GitHub Check: autofix
🔇 Additional comments (5)
packages/db/migrations/1763457421_smiling_elektra.sql (2)
1-4: Constraint naming standardization looks good for most tables.The migration standardizes constraint names to snake_case across model_history, model_provider_mapping, model_provider_mapping_history, and provider_key tables. This is consistent with the PR objective of naming standardization.
5-6: Clarify the inconsistent constraint type suffix on organization table.Lines 5–6 rename organization's unique constraints but change the suffix from
_uniqueto_key, deviating from the pattern in lines 1–4 where the_uniquesuffix is preserved. While_keyis a valid PostgreSQL convention for unique constraints, this inconsistency within the same migration is worth clarifying.
- Is the use of
_keysuffix for organization constraints intentional (e.g., following a specific naming convention for this table), or should it follow the same_uniquepattern as the other tables?- Verify that
organization_stripeCustomerId_uniqueandorganization_stripeSubscriptionId_uniqueexist in the current schema.- Verify that the new names (
organization_stripe_customer_id_keyandorganization_stripe_subscription_id_key) do not conflict with any existing constraints.packages/db/migrations/meta/_journal.json (1)
454-458: New journal entry looks good.Idx 64, tag 1763457421_smiling_elektra, v8 with breakpoints=true is consistent with the snapshot upgrades.
packages/db/migrations/meta/1747915707_snapshot.json (1)
332-341: Uniques present and well-named.api_key_token_unique, session_token_unique, user_email_unique look consistent with snake_case standardization.
Also applies to: 1571-1580, 1715-1724
packages/db/migrations/meta/1747927048_snapshot.json (1)
1296-1311: Project toggles look consistent.caching_enabled and cache_duration_seconds defaults align across snapshots.
Also applies to: 1329-1343
| "type": "numeric", | ||
| "typeSchema": null, | ||
| "notNull": true, | ||
| "dimensions": 0, | ||
| "default": { | ||
| "type": "unknown", | ||
| "value": "'0'" | ||
| }, | ||
| "generated": null, | ||
| "identity": null, | ||
| "name": "credits", | ||
| "schema": "public", | ||
| "table": "organization", | ||
| "entityType": "columns" | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
Verify default for numeric(credits) renders as numeric 0.
Default is represented as "'0'". Ensure generated SQL is DEFAULT 0 (numeric), not a text literal.
🏁 Script executed:
#!/usr/bin/env bash
# Inspect how defaults are emitted in generated SQL (if available in repo artifacts)
fd -a -g 'packages/db/migrations/*' | rg -nP 'CREATE TABLE.*organization|credits|DEFAULT'Length of output: 0
🏁 Script executed:
#!/bin/bash
# Explore migration directory structure and identify migration system
echo "=== Migration directory structure ==="
find packages/db/migrations -type f -name "*.json" -o -name "*.ts" -o -name "*.js" | head -20
echo -e "\n=== Check package.json for migration tool ==="
cat packages/db/package.json | grep -A5 -B5 "drizzle\|knex\|migrate\|sql"
echo -e "\n=== Look for migration generation code ==="
fd -g "*.ts" -g "*.js" packages/db | xargs rg -l "DEFAULT|default.*numeric\|0.*numeric" -C2 | head -10Length of output: 2049
🏁 Script executed:
#!/bin/bash
# Check the actual snapshot file for context on how defaults are structured
echo "=== Check nearby entries in snapshot.json for comparison ==="
jq '.schemas[0].tables[0].columns | .[0:5]' packages/db/migrations/meta/1747930278_snapshot.json 2>/dev/null | head -50Length of output: 65
🏁 Script executed:
#!/bin/bash
# Search for migration generation or SQL building logic
echo "=== Search for how 'unknown' type defaults are handled ==="
rg -n "type.*unknown\|DEFAULT.*0|'0'" packages/db --type ts --type js -C3 | head -40Length of output: 58
🏁 Script executed:
#!/bin/bash
# Look for the actual generated SQL if available
echo "=== Search for generated migration SQL files ==="
find packages/db -name "*.up.sql" -o -name "*.down.sql" -o -name "*migration*.sql" 2>/dev/null | xargs cat 2>/dev/null | grep -A3 -B3 "organization\|credits" | head -30Length of output: 48
🏁 Script executed:
#!/bin/bash
# Read the snapshot file directly to inspect structure
echo "=== First 100 lines of snapshot ==="
head -100 packages/db/migrations/meta/1747930278_snapshot.jsonLength of output: 2235
🏁 Script executed:
#!/bin/bash
# Search for organization table schema in codebase
echo "=== Search for 'organization' table schema definition ==="
rg -n "organization\|credits" packages/db/src --type ts -C5 | head -60Length of output: 57
🏁 Script executed:
#!/bin/bash
# Look for Drizzle schema files
echo "=== Find schema definition files ==="
fd -g "*.ts" -g "*.js" packages/db/src | xargs rg -l "table\|schema" | head -20Length of output: 87
🏁 Script executed:
#!/bin/bash
# Check how defaults are defined in schema
echo "=== Search for numeric default patterns in schema ==="
rg -n "\.default\(|numeric\|num\(" packages/db/src --type ts -B2 -A2 | head -50Length of output: 2668
🏁 Script executed:
#!/bin/bash
# Find the organization table definition in schema and surrounding context
echo "=== Find organization table full definition ==="
rg -n "organization\|createTable" packages/db/src/schema.ts -A30 | head -80Length of output: 47
🏁 Script executed:
#!/bin/bash
# Look for any generated SQL or migration output files
echo "=== Search for any SQL output or migration logs ==="
find packages/db -type f \( -name "*.sql" -o -name "*.log" -o -name "*.out" \) 2>/dev/null | xargs cat 2>/dev/null | head -50Length of output: 1517
🏁 Script executed:
#!/bin/bash
# Check how Drizzle decimal defaults are defined in the codebase
echo "=== Review all decimal field defaults ==="
rg -n "decimal()" packages/db/src/schema.ts -B1 -A3Length of output: 1509
🏁 Script executed:
#!/bin/bash
# Inspect the snapshot for the organization table specifically
echo "=== Extract organization table from snapshot ==="
jq '.ddl[] | select(.table == "organization")' packages/db/migrations/meta/1747930278_snapshot.json | head -100Length of output: 1792
🏁 Script executed:
#!/bin/bash
# Search the SQL file for the organization table creation
echo "=== Find organization CREATE TABLE in generated SQL ==="
rg -n "CREATE TABLE.*organization\|\"organization\"" packages/db -A50 | head -100Length of output: 55
🏁 Script executed:
#!/bin/bash
# Check if there's a specific migration file for organization.credits
echo "=== Search for migration files mentioning credits ==="
find packages/db/migrations -type f -name "*.sql" -exec grep -l "credits" {} \;Length of output: 166
🏁 Script executed:
#!/bin/bash
# Verify Drizzle documentation pattern for decimal defaults
echo "=== Check other decimal default patterns for comparison ==="
jq '.ddl[] | select(.type == "numeric" and .default != null)' packages/db/migrations/meta/1747930278_snapshot.jsonLength of output: 343
🏁 Script executed:
#!/bin/bash
# Read the migration files containing credits
echo "=== Migration 1747927048 ==="
cat packages/db/migrations/1747927048_flimsy_black_tom.sqlLength of output: 204
🏁 Script executed:
#!/bin/bash
# Read the second migration
echo "=== Migration 1749245675 ==="
cat packages/db/migrations/1749245675_cuddly_krista_starr.sqlLength of output: 652
Change default("0") to default(0) for numeric type correctness.
The generated SQL renders DEFAULT '0' (text literal with quotes) instead of the correct DEFAULT 0 (numeric literal). While PostgreSQL's implicit cast handles this, it violates type safety.
Schema location: packages/db/src/schema.ts:123
Current: credits: decimal().notNull().default("0")
Should be: credits: decimal().notNull().default(0)
The issue is confirmed in the migration: ALTER TABLE "organization" ADD COLUMN "credits" numeric DEFAULT '0' NOT NULL;
🤖 Prompt for AI Agents
In packages/db/migrations/meta/1747930278_snapshot.json around lines 912-926 and
in packages/db/src/schema.ts at line 123, the numeric column default is stored
as a string ('0') causing the migration to emit DEFAULT '0' instead of DEFAULT
0; change the schema to use a numeric default and update the migration snapshot:
in packages/db/src/schema.ts replace decimal().notNull().default("0") with
decimal().notNull().default(0), then regenerate or edit the migration snapshot
so the column's default is numeric (type numeric/unknown value 0 or equivalent
without quotes) and re-run migrations/tests to confirm the SQL now emits DEFAULT
0.
1 participant
Summary by CodeRabbit