-
-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Selective supabase migration squash
#2239
Comments
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. |
Yes, this is the use case, merging the N last, non applied scripts. What if I have applied local scripts? I don't want to mess the migration 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: