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
Migration checksum EOL-independent #7101
Comments
See code for documentation on the how and why. Relevant issues: - prisma/prisma#7398 - prisma/prisma#7101
See code for documentation on the how and why. Relevant issues: - prisma/prisma#7398 - prisma/prisma#7101
See code for documentation on the how and why. Relevant issues: - prisma/prisma#7398 - prisma/prisma#7101
See code for documentation on the how and why. Relevant issues: - prisma/prisma#7398 - prisma/prisma#7101
…2101) * Encapsulate checksum handling into a module in MigrationConnector * Make checksum comparison try matching with lf and crlf line endings See code for documentation on the how and why. Relevant issues: - prisma/prisma#7398 - prisma/prisma#7101
A fix just got released in the dev channel on npm (not recommended for production). If you can try this specific version It will be released next Tuesday in our biweekly release. |
Great news, but I'm not sure how to test this without breaking my old migrations. |
@andreamatt I checked with @do4gr and this should be backward compatible so it should not break the old migrations. It calculates several checksums and if any matches it will be ok. |
Fix included in 2.29 release planned for tomorrow, August 10. |
Problem
Migrations have a checksum that depends on the EOL char.
I generate migrations on linux, push them, then my collegue on windows has a "migration modified after it was applied" issue.
Our current workaround is adding a .gitattributes so that git treats migrations' sql as binary (without changing newline on checkout).
Suggested solution
Replace the newline char to LF before performing the checksum, so that the checksum is EOL-independent.
The text was updated successfully, but these errors were encountered: