> if your latest migration is destructive - you want to seed data and then run the next migration.
We have added supabase migration up [0] command that runs only pending migrations (ie. those that don't exist in local db's migration history table). You can use that to test destructive migration locally with data from seed.sql.
After testing, you want to update your seed.sql with a data-only dump [1] from your local db. That would make CI happy with both the new migration and the new seed file.
> 2. run a preseed script that disables any triggers and removes default data that has been previously seeded in migrations
It sounds like the default data is no longer relevant for your local development. If so, I would suggest running supabase migration squash [2] to remove the default data.
To disable triggers before seeding data, you can add the following line to seed.sql [3]
We have added supabase migration up [0] command that runs only pending migrations (ie. those that don't exist in local db's migration history table). You can use that to test destructive migration locally with data from seed.sql.
After testing, you want to update your seed.sql with a data-only dump [1] from your local db. That would make CI happy with both the new migration and the new seed file.
> 2. run a preseed script that disables any triggers and removes default data that has been previously seeded in migrations
It sounds like the default data is no longer relevant for your local development. If so, I would suggest running supabase migration squash [2] to remove the default data.
To disable triggers before seeding data, you can add the following line to seed.sql [3]
SET session_replication_role = replica;
[0] https://supabase.com/docs/reference/cli/supabase-migration-u...
[1] https://supabase.com/docs/reference/cli/supabase-db-dump
[2] https://supabase.com/docs/reference/cli/supabase-migration-s...
[3] https://stackoverflow.com/questions/3942258/how-do-i-tempora...