You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
I'm a little bit frustrated when preparing for a production deployment using supabase migration squash command because it consolidates all migrations, including those already applied to the production database. This can lead to unnecessary complications and the need to manually select which migrations to include for production environments. We have a --version argument but this not let us to select a range of versions, for example.
Describe the solution you'd like
I would like the supabase migration squash command to include an option to squash only migrations that have not yet been applied to the remote production database. This would streamline the process of preparing migrations for production by automatically generating a single migration script from the unapplied migrations, thus reducing the risk of errors and manual filtering.
Describe alternatives you've considered
An alternative could be manually filtering out the applied migrations and only squashing the remaining ones, but this is error-prone and not scalable for teams or frequent deployments.
Additional context
Adding parameters such as --unapplied-only to the squash command could be a straightforward solution to ensure that only new, unapplied migrations are included in the squashed file. This would make the migration process much more efficient and error-free for teams moving changes to production environments.
The text was updated successfully, but these errors were encountered:
Say you have migrations 1-6 and you would like to squash just 5-6? Since these are unapplied migrations, I wonder if you can simply concatenate these local migration files manually?
One technical limitation of squash is that it uses pg_dump to capture all schema changes since the beginning of all migrations. If we start squashing from a version in the middle, the pg_dump output may not be diffed perfectly as later migrations could modify an existing table.
Is your feature request related to a problem? Please describe.
I'm a little bit frustrated when preparing for a production deployment using
supabase migration squash
command because it consolidates all migrations, including those already applied to the production database. This can lead to unnecessary complications and the need to manually select which migrations to include for production environments. We have a--version
argument but this not let us to select a range of versions, for example.Describe the solution you'd like
I would like the supabase migration squash command to include an option to squash only migrations that have not yet been applied to the remote production database. This would streamline the process of preparing migrations for production by automatically generating a single migration script from the unapplied migrations, thus reducing the risk of errors and manual filtering.
Describe alternatives you've considered
An alternative could be manually filtering out the applied migrations and only squashing the remaining ones, but this is error-prone and not scalable for teams or frequent deployments.
Additional context
Adding parameters such as
--unapplied-only
to the squash command could be a straightforward solution to ensure that only new, unapplied migrations are included in the squashed file. This would make the migration process much more efficient and error-free for teams moving changes to production environments.The text was updated successfully, but these errors were encountered: