PHP 8: "PDOException: There is no active transaction"

[forgie1]

Under PHP 8 there is Exception thrown, when transaction was autocommited.
PDOException: There is no active transaction
This is the change in PHP sources: php/php-src@990bb34

Ideal would be not to throw the exception if transaction was already commited.

This is similar to this issue in unrelated project: yiisoft/yii2#18406

[greg0ire]

Ideal would be not to throw the exception if transaction was already commited.

Why would we hide this fact to our users?

[forgie1]

Because user want to commit already commited transaction. So all is fine basically. No Exception is needed.
This was +/- default behavior of PHP prior version 8.

But I'm little confused since MariaDb doc states something different:
https://mariadb.com/kb/en/start-transaction/#ddl-statements

DDL statements (CREATE, ALTER, DROP) and administrative statements (FLUSH, RESET, OPTIMIZE, ANALYZE, CHECK, REPAIR, CACHE INDEX), and LOAD DATA INFILE, cause an implicit COMMIT and start a new transaction.

But it looks to me it is about PHP version not the Database.
Because in PHP 8 new transaction is not started, as it was prior PHP 8 -- I tested it on the same database. And PHP 8 furthermore throws useless exception.

[greg0ire]

if transaction was already commited.

Please elaborate. What code using doctrine/orm can be used to reproduce this? What feature are you referring to? Do you have a link to Doctrine ORM docs about this?

[alexgit2k]

Reproduceable with

symfony new application --full
cd application
sed -i 's/Type::JSON_ARRAY/"json_array"/' vendor/symfony/maker-bundle/src/Maker/MakeEntity.php # Fix other bug
vi .env # Configure DATABASE_URL
symfony console make:entity A

New property name (press to stop adding fields):

symfony console make:entity B
New property name (press to stop adding fields):

a

Field type (enter ? to see all types) [string]:

ManyToOne

What class should this entity be related to?:

A

Is the B.a property allowed to be null (nullable)? (yes/no) [yes]:

Do you want to add a new property to A so that you can access/update B objects from it - e.g. $a->getBs()? (yes/no) [yes]:

A new property will also be added to the A class so that you can access the related B objects from it.

New field name inside A [bs]:

updated: src/Entity/B.php
updated: src/Entity/A.php

Add another property? Enter the property name (or press to stop adding fields):

symfony console make:migration
symfony console doctrine:migrations:migrate

Error
In Connection.php line 144:

There is no active transaction

exit status 1

Workaround
Execute migration again
symfony console doctrine:migrations:migrate
At the second time it says: [OK] Already at the latest version ("DoctrineMigrations\Version20211017094854")

[greg0ire]

Ok so your issue is when executing symfony console doctrine:migrations:migrate. Let's transfer this issue to the right repository.

[greg0ire]

Please get a stack trace for the migrate command that fails. Please also read https://www.doctrine-project.org/projects/doctrine-migrations/en/3.3/explanation/implicit-commits

[alexgit2k]

The above example (#1202 (comment)) produces a CREATE TABLE and I'm using MySQL which is not supported in transactions as https://github.com/doctrine/migrations/blob/3.2.x/docs/en/explanation/implicit-commits.rst says.

However, adding isTransactional with return false in a migration did not help

  Context: attempting to execute migrations with all-or-nothing enabled
  Problem: migration DoctrineMigrations\Version20211017111436 is marked as non-transactional
  Solution: disable all-or-nothing in configuration or by command-line option, or enable transactions for all migrations

I do have an Exception trace of the "There is no active transaction"-error:

Exception trace:
  at application/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:144
 PDO->rollBack() at application/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:144
 Doctrine\DBAL\Driver\PDO\Connection->rollBack() at application/vendor/doctrine/dbal/src/Connection.php:1419
 Doctrine\DBAL\Connection->rollBack() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/Tools/TransactionHelper.php:55
 Doctrine\Migrations\Tools\TransactionHelper::rollbackIfInTransaction() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/Version/DbalExecutor.php:257
 Doctrine\Migrations\Version\DbalExecutor->migrationEnd() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/Version/DbalExecutor.php:115
 Doctrine\Migrations\Version\DbalExecutor->execute() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/DbalMigrator.php:112
 Doctrine\Migrations\DbalMigrator->executePlan() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/DbalMigrator.php:76
 Doctrine\Migrations\DbalMigrator->executeMigrations() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/DbalMigrator.php:162
 Doctrine\Migrations\DbalMigrator->migrate() at application/vendor/doctrine/migrations/lib/Doctrine/Migrations/Tools/Console/Command/MigrateCommand.php:210
 Doctrine\Migrations\Tools\Console\Command\MigrateCommand->execute() at application/vendor/symfony/console/Command/Command.php:299
 Symfony\Component\Console\Command\Command->run() at application/vendor/symfony/console/Application.php:996
 Symfony\Component\Console\Application->doRunCommand() at application/vendor/symfony/framework-bundle/Console/Application.php:96
 Symfony\Bundle\FrameworkBundle\Console\Application->doRunCommand() at application/vendor/symfony/console/Application.php:295
 Symfony\Component\Console\Application->doRun() at application/vendor/symfony/framework-bundle/Console/Application.php:82
 Symfony\Bundle\FrameworkBundle\Console\Application->doRun() at application/vendor/symfony/console/Application.php:167
 Symfony\Component\Console\Application->run() at application/vendor/symfony/runtime/Runner/Symfony/ConsoleApplicationRunner.php:56
 Symfony\Component\Runtime\Runner\Symfony\ConsoleApplicationRunner->run() at application/vendor/autoload_runtime.php:35
 require_once() at application/bin/console:11

[greg0ire]

Context: attempting to execute migrations with all-or-nothing enabled
Problem: migration DoctrineMigrations\Version20211017111436 is marked as non-transactional
Solution: disable all-or-nothing in configuration or by command-line option, or enable transactions for all migrations

Hey! I wrote this error message! What do you think about it?

[kbond]

Not sure if zenstruck/foundry#207 is related but I discovered this error only occurs when php >= 8 and dbal >= 3. With php 8 and dbal 2.13.4, no error.

[greg0ire]

🤔 it's weird that the DBAL has an impact here, but maybe that's because it has some influence on the version of some other packages?

[kbond]

It works as expected when I add a dbal 3 conflict - dbal is the only package that changes.

[alexgit2k]

Context: attempting to execute migrations with all-or-nothing enabled
Problem: migration DoctrineMigrations\Version20211017111436 is marked as non-transactional
Solution: disable all-or-nothing in configuration or by command-line option, or enable transactions for all migrations

Hey! I wrote this error message! What do you think about it?

When trying to work around the initial bug, I played with all_or_nothing in config/packages/doctrine_migrations.yaml and forgot it there. So it's working bei either adding isTransactional afterwards to migrations/Version* or by setting transactional: false in config/packages/doctrine_migrations.yaml before creating the migrations with symfony console make:migration (https://www.doctrine-project.org/projects/doctrine-migrations/en/3.3/explanation/implicit-commits)

However, I expect that it is working by default. So when using MySQL/MariaDB/Oracle transactional should be set to false automatically, as they do not support transactional DDL-statements or at least if DDL-statements are used in a migration.

[kbond]

Thanks @alexgit2k, overriding AbstractMigration::isTransactional() and returning false fixed zenstruck/foundry#207. Not sure why this fixed it (or why it works without this change in dbal 2).

[greg0ire]

However, I expect that it is working by default. So when using MySQL/MariaDB/Oracle transactional should be set to false automatically, as they do not support transactional DDL-statements or at least if DDL-statements are used in a migration.

I think we have considered and rejected this in the past. You can read the very long #1104 and all link threads, and IMO you should be able to learn more about what lead to the current situation here. Closing.

[kbond]

Thanks for the link @greg0ire, I understand the issue better now.

[alexgit2k]

@greg0ire I know it now, but for other developers throwing this exception without further information is just PITA. Or you just want to punish them for using MySQL/MariaDB/Oracle ;-)

[greg0ire]

I know it now, but for other developers throwing this exception without further information is just PITA.

Can we really be sure this error message will only ever happen in that situation?

Or you just want to punish them for using MySQL/MariaDB/Oracle

👼

[alexgit2k]

I know it now, but for other developers throwing this exception without further information is just PITA.

Can we really be sure this error message will only ever happen in that situation?

I don't know, but accordingly to #1104 this wasn't an issue with earlier versions of doctrine-migrations.

It has also been fixed in doctrine-migrations 2.3 (#1104 (comment)), but I haven't found a fix for doctrine-migrations 3, although #1104 has been closed.

[greg0ire]

It has also been fixed in doctrine-migrations 2.3 (#1104 (comment))

Yes, but then see #1170 , we changed our mind about this.

I don't know, but accordingly to #1104 this wasn't an issue with earlier versions of doctrine-migrations.

Can you quote a specific comment? #1104 is a few kilometers long.

[boctulus]

I have SAME problem in my own framework exactly trying to excecute MIGRATIONS with PHP 8+

Any glue about what is the cause for it?

[greg0ire]

@boctulus have you read and understood https://www.doctrine-project.org/projects/doctrine-migrations/en/stable/explanation/implicit-commits ?