refactor: improve Atlas migration management with better baseline handling #507
Conversation
|
|
View your CI Pipeline Execution ↗ for commit 9ee0fa1
☁️ Nx Cloud last updated this comment at |
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
| sed -i 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql | ||
|
|
||
| # Strip date-specific partitions (they change daily, we don't reference them) | ||
| # e.g., messages_2025_12_04, messages_2025_12_05, etc. | ||
| sed -i '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql |
There was a problem hiding this comment.
The sed -i command has portability issues between Linux and macOS. On macOS, sed -i requires a backup extension argument (e.g., sed -i ''), while Linux uses sed -i directly. This will cause the script to fail on macOS with the error: "invalid command code" due to the set -euo pipefail at line 14.
Fix:
# Use a cross-platform approach
sed 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql > supabase-baseline-schema.sql.tmp
mv supabase-baseline-schema.sql.tmp supabase-baseline-schema.sql
sed '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql > supabase-baseline-schema.sql.tmp
mv supabase-baseline-schema.sql.tmp supabase-baseline-schema.sqlOr detect the OS:
if [[ "$OSTYPE" == "darwin"* ]]; then
sed -i '' 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql
sed -i '' '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql
else
sed -i 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql
sed -i '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql
fi| sed -i 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql | |
| # Strip date-specific partitions (they change daily, we don't reference them) | |
| # e.g., messages_2025_12_04, messages_2025_12_05, etc. | |
| sed -i '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql | |
| # Strip VERSION strings that change with every dump | |
| if [[ "$OSTYPE" == "darwin"* ]]; then | |
| sed -i '' 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql | |
| else | |
| sed -i 's/ VERSION "[^"]*"//g' supabase-baseline-schema.sql | |
| fi | |
| # Strip date-specific partitions (they change daily, we don't reference them) | |
| # e.g., messages_2025_12_04, messages_2025_12_05, etc. | |
| if [[ "$OSTYPE" == "darwin"* ]]; then | |
| sed -i '' '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql | |
| else | |
| sed -i '/messages_20[0-9]\{2\}_[0-9]\{2\}_[0-9]\{2\}/d' supabase-baseline-schema.sql | |
| fi | |
Spotted by Graphite Agent
Is this helpful? React 👍 or 👎 to let us know.
jumski
force-pushed
the
12-05-refactor_atlas_baseline_to_use_fresh_hosted_supabase_schema
branch
2 times, most recently
from
9561a5c to
08e5f14
Compare
jumski
force-pushed
the
12-05-refactor_atlas_baseline_to_use_fresh_hosted_supabase_schema
branch
from
08e5f14 to
6797882
Compare
jumski
force-pushed
the
12-05-refactor_atlas_baseline_to_use_fresh_hosted_supabase_schema
branch
from
6797882 to
9ee0fa1
Compare
| |-----------|---------|-------------|-------| | ||
| | pgmq | v1.5.1 | 1.5.1 | pgflow dependency (not in Supabase image) | | ||
| | pg_cron | v1.6.4 | 1.6 | Scheduled jobs (v1.6.3+ for PG17) | | ||
| | pg_net | v0.7.1 | 0.20.2 | HTTP requests from SQL | |
There was a problem hiding this comment.
Documentation mismatch: The table shows pg_net Git Tag as v0.7.1, but the Dockerfile (line 43) checks out v0.20.2. This inconsistency will confuse developers about which version is actually installed.
Fix:
| pg_net | v0.20.2 | 0.20.2 | HTTP requests from SQL || | pg_net | v0.7.1 | 0.20.2 | HTTP requests from SQL | | |
| | pg_net | v0.20.2 | 0.20.2 | HTTP requests from SQL | |
Spotted by Graphite Agent
Is this helpful? React 👍 or 👎 to let us know.
| atlas schema inspect \ | ||
| --schema realtime,vault \ |
There was a problem hiding this comment.
Critical bug: The script only inspects realtime,vault schemas, but the committed baseline file includes the pgsodium schema (lines 1-2 and 7-8 of supabase-baseline-schema.sql). When this script is run, it will regenerate a baseline missing the pgsodium schema, causing Atlas migration diffs to incorrectly try to drop/recreate pgsodium.
Fix:
atlas schema inspect \
--schema realtime,vault,pgsodium \| atlas schema inspect \ | |
| --schema realtime,vault \ | |
| atlas schema inspect \ | |
| --schema realtime,vault,pgsodium \ | |
Spotted by Graphite Agent
Is this helpful? React 👍 or 👎 to let us know.
🔍 Preview Deployment: Website✅ Deployment successful! 🔗 Preview URL: https://pr-507.pgflow.pages.dev 📝 Details:
_Last updated: _ |
Improved Atlas Migration Management for Supabase Integration
This PR enhances our database migration workflow by improving how we handle the Supabase baseline schema:
atlas/README.mdexplaining the migration system, baseline schema, and extension managementdump-fresh-baseline.shscript that properly captures a fresh Supabase project schemasupabase-baseline-schema.sql)dump-realtime-schemaNX taskThis approach is more reliable as it: