-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Renaming migrations #1158
Comments
Even without changing the names, I've been running into the issue of Rubber-duck edit: After looking into this a bit, it seems that the checksum reported for the local migration when the check is run is comparing with the To test this on your own, run I'll make a fix and open a PR to resolve this. It shouldn't require any changes to stored data as it's entirely within the CLI - the checksums stored are correct. |
When running `sqlx migrate info`, the applied migrations checksums are compared against the checksums of the local migration files. While the checksums of applied migrations are stored correctly in the database as sha384sum values, the `migrate info` command was incorrectly comparing these against the checksums of down-migrations in cases where reversible migrations are being used (e.g. when migrations end in `.up.sql` and `.down.sql`). This fixes the issue by skipping over any migrations with the `MigrationType::ReversibleDown` type, using the same idiom as is used when running migrations (with `migrate run`). Issue introduced in launchbadge#1680 Partially resolves launchbadge#1158
When running `sqlx migrate info`, the applied migrations checksums are compared against the checksums of the local migration files. While the checksums of applied migrations are stored correctly in the database as sha384sum values, the `migrate info` command was incorrectly comparing these against the checksums of down-migrations in cases where reversible migrations are being used (e.g. when migrations end in `.up.sql` and `.down.sql`). This fixes the issue by skipping over any migrations with the `MigrationType::ReversibleDown` type, using the same idiom as is used when running migrations (with `migrate run`). Issue introduced in launchbadge#1680 Partially resolves launchbadge#1158
When running `sqlx migrate info`, the applied migrations checksums are compared against the checksums of the local migration files. While the checksums of applied migrations are stored correctly in the database as sha384sum values, the `migrate info` command was incorrectly comparing these against the checksums of down-migrations in cases where reversible migrations are being used (e.g. when migrations end in `.up.sql` and `.down.sql`). This fixes the issue by skipping over any migrations with the `MigrationType::ReversibleDown` type, using the same idiom as is used when running migrations (with `migrate run`). Issue introduced in launchbadge#1680 Partially resolves launchbadge#1158
When running `sqlx migrate info`, the applied migrations checksums are compared against the checksums of the local migration files. While the checksums of applied migrations are stored correctly in the database as sha384sum values, the `migrate info` command was incorrectly comparing these against the checksums of down-migrations in cases where reversible migrations are being used (e.g. when migrations end in `.up.sql` and `.down.sql`). This fixes the issue by skipping over any migrations with the `MigrationType::ReversibleDown` type, using the same idiom as is used when running migrations (with `migrate run`). Issue introduced in launchbadge#1680 Partially resolves launchbadge#1158
When running `sqlx migrate info`, the applied migrations checksums are compared against the checksums of the local migration files. While the checksums of applied migrations are stored correctly in the database as sha384sum values, the `migrate info` command was incorrectly comparing these against the checksums of down-migrations in cases where reversible migrations are being used (e.g. when migrations end in `.up.sql` and `.down.sql`). This fixes the issue by skipping over any migrations with the `MigrationType::ReversibleDown` type, using the same idiom as is used when running migrations (with `migrate run`). Issue introduced in #1680 Partially resolves #1158
Hi there, I was looking for a way to rename a migration (not change its content) or at least force it to reapply (I always try to make them idempotent), but sqlx fails saying its checksum has changed even though it hasn't.
Is that expected, is there a proper way to rename a migration?
The text was updated successfully, but these errors were encountered: