Migrations Always Starting a Transaction

[BusterNeece]

Bug Report

Q	A
Version	3.7.4

Summary

Trying to track down an issue I'm having since updating to ORM 3, DBAL 4 and the latest Migrations library.

Basically, regardless of what setting I provide at the global configuration level for the transactional variable, it seems to still be wrapping every migration in a transaction that it isn't then exiting out of at the end of that migration completing successfully.

This means that if I have 30 database migrations to execute, I'll wind up, at the end of that command's execution, with a nesting level of 30 as reported by the DBAL.

I've gone digging through the relevant code and found that currently the only place the migrator executor is checking for whether or not to wrap each migration in a transaction is in AbstractMigration::isTransactional. It doesn't seem to be using the global configuration for that at all currently.

As for why it isn't committing those transactions when successful, I haven't been able to figure that out.

I suspect that this has been a nonissue for most users because they run DB migrations as an isolated command, and the migrations do complete successfully either way, so whatever state the DBAL is left in after the migrations execute is of no concern to most people implementing the library. In my case, I execute a few other "cleanup" commands after the migrations complete, and it's these commands that break as a result of the DBAL being left, by the migrator, in a state with nested transactions that it can't seem to deal with properly.

Current behaviour

Previously this didn't cause any problems in earlier versions of the Migrations library, though unfortunately I upgraded to both DBAL 4 and ORM 3 at the same time, meaning the error could theoretically be in any of the relevant upstream projects. I was able, however, to identify at least one specific problem (the isTransactional check above not using the global config value at all), that likely merits fixing on this library's level.

I can confirm, however, that if you return false on isTransactional for all migration classes themselves, they won't wrap in a transaction and this is not an issue.

How to reproduce

I'll work on getting this in a reproducible way; right now it's embedded in a rather complex application that would be difficult to pull apart for diagnostics here.

Expected behaviour

Either for migrations to not take place wrapped in transactions at all (honoring the is_transactional global setting sent to migration config) or for the nested transaction level at the end of multiple migrations to be 0.

[derrabus]

Is your database a MySQL or MariaDB by any chance?

[BusterNeece]

@derrabus MariaDB, yes

[derrabus]

See #1426.

[BusterNeece]

Yep, closing this in favor of that. Same thing.