-
Notifications
You must be signed in to change notification settings - Fork 215
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
sqitch add suddently uses same template for all engines while add.all = true
#795
Labels
Comments
Yay, someone is using templates sufficiently to surface this bug! Confirmed it is a bug, mostly because it was never updated to support adding change scripts to multiple engines at once, which was implemented all the way back in 0c7237c. |
theory
added a commit
that referenced
this issue
Oct 21, 2023
When adding a change to multiple engines, Sqitch would randomly pick one engine's templates or the others and create them all for the same engine. In other words, adding a change to both "sqlite" and "pg" targets would result in all change files generated from templates from only one of those engines -- whichever it happened to find first. Due to the use of a hash reference for templates in add.pm. Fix it by making a copy of the hash instead. This leads to duplication of effort when multiple targets use the same engine, but the cost is generally low relative to how often `add` is called -- and likely is measured in milliseconds. Resolves #795.
This was referenced Oct 21, 2023
theory
added a commit
that referenced
this issue
Oct 21, 2023
When adding a change to multiple engines, Sqitch would randomly pick one engine's templates or the others and create them all for the same engine. In other words, adding a change to both "sqlite" and "pg" targets would result in all change files generated from templates from only one of those engines -- whichever it happened to find first. Due to the use of a hash reference for templates in add.pm. Fix it by making a copy of the hash instead. This leads to duplication of effort when multiple targets use the same engine, but the cost is generally low relative to how often `add` is called -- and likely is measured in milliseconds. Resolves #795.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
I recently started using sqitch for my DB migration management. I use MySQL for production and SQLite for quick testing. I use
sqlfluff
for linting and autoformatting my SQL scripts.Because sqlfluff complains about
BEGIN
in MySQL Scripts, which is used in the sqitch default template for MySQL, I added custom templates to useSTART TRANSACTION
in MySQL Scripts.What I want
I want sqitch to create scripts for both SQLite and MySQL from there respective templates when I run e.g.
sqitch add test -n "test"
.What I get
When I run
sqitch add test -n "test"
I correctly get 6test.ddl
Scripts like shown in the file tree below. But the content of those files is the problem. At random sqitch chooses to either use MySQL or SQLite templates for both engines. The examples below are from the case MySQL templates were used.I already did 2 migrations with sqitch before today and I added the templates before the first migration. So the setup worked 2 times already. So I am really confused why it suddenly stopped working.
I also tried checking out the commit where I added the templates and running
sqitch add test -n "test"
, but I get the same bogus result.Version
I installed sqitch around 7 weeks ago (according to git) and never updated it, but v1.4.0 is the most recent so it should not matter.
OS
ubuntu 22.04.1
sqitch.conf
Truncated file tree in my repo:
Templates
migrations/templates/deploy/mysql.tmpl
migrations/templates/deploy/sqlite.tmpl
migrations/templates/revert/mysql.tmpl
migrations/templates/revert/sqlite.tmpl
migrations/templates/verify/mysql.tmpl
migrations/templates/verify/sqlite.tmpl
Migration files
migrations/mysql/deploy/test.ddl
migrations/mysql/revert/test.ddl
migrations/mysql/verify/test.ddl
migrations/sqlite/deploy/test.ddl
migrations/sqlite/revert/test.ddl
migrations/sqlite/verify/test.ddl
The text was updated successfully, but these errors were encountered: