-
-
Notifications
You must be signed in to change notification settings - Fork 28
Description
this was admittedly a little silly but:
I had a migration like this:
-- upgrade from version 4 to version 5
SET autocommit = 0;
BEGIN;
# (for this bug, the actual statement doesnt matter)
ALTER TABLE `some_table` ADD `whatever` ....... blah .....;
COMMIT;
That was the last migration in a series of migrations (say going from version 3 to version 5).
The migration above succeeded, and I expected that the "migration_version" table would look like this at the end:
status="complete", version=5
but instead I was seeing this:
status="partial up", version=5
What was happening is because "autocommit" was being turned off by the migration SQL, the byjg/migration library executed the UPDATE statement to set it to "complete", version=5, but never explicitly committed the transaction, so, it was never actually written to the DB.
So, the version number was left in the last state it was in previously which was "partial up", version=5
I realize it's a bit silly to use "autocommit=0" when I'm also doing explicit BEGIN/COMMIT to mark the start/end of a tranasction. I've removed that from my SQL scripts.
but, I feel like having the migration library explicitly commit after updating the table is a good idea anyway just in case your users do something silly, like what I did : ) perhaps adding $this->getDbDriver()->commitTransaction();
in the setVersion() function (and maybe in other places)
Love the library, thanks!
*Edited to fix one detail about the version#