DAMA 8 breaks Foundry and blocks upgrading to Symfony 7

[Fabrn]

Hi everyone !

I know there is a long time "bug" while using Foundry with DAMA if you have the use_savepoints configuration to true. I don't know the state of it right now, so I'm sorry if it has already been discussed previously.

The problem is that DAMA has upgraded to version 8 at the end of last year, and it is now required to set the use_savepoints configuration to true. Also, DAMA v7 does not support Symfony 7, which means that if you use Foundry with DAMA, you cannot upgrade your project to Symfony 7, which is real shame.

I don't really know where I should create this issue, whether here or on DAMA's repo. Also I don't know what we can do about it but I think we must find a solution 😄

Maybe DAMA v7 should support Symfony 7, but I think this is only buying time and does not resolve the core issue here.

Thanks in advance and have a great day 🙂

[nikophil]

Hi @Fabrn

could you elaborate about the problem? sorry if you've already done it in another issue, let's start from a fresh one.

I can tell you that I'm using Foundry 2 / Dama 8 / Symfony 7 in several projects, and it works like a charm.

I guess you're using the migrate mode? (which I don't use in those projects)

[Fabrn]

Hi @Fabrn

could you elaborate about the problem? sorry if you've already done it in another issue, let's start from a fresh one.

I can tell you that I'm using Foundry 2 / Dama 8 / Symfony 7 in several projects, and it works like a charm.

I guess you're using the migrate mode? (which I don't use in those projects)

Hi ! Thanks for the quick answer 🙂

Yes I am using the migrate mode. If I don't, our database reset is VERY long (between 1 and a half minute and 2 minutes). I saved some time making a migration and using the migrate mode.

Is the savepoint problem + migrate mode an issue that cannot be solved ?

[nikophil]

Is the savepoint problem + migrate mode an issue that cannot be solved ?

I can't say, I I don't know the problem 😁

[Fabrn]

All I can say is that it happens while resetting the database. The StoryManager is called, which builds every Story and causes the PDOException: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist error once the first element of the Story is persisted.

The stack trace is the following :

/application/vendor/doctrine/dbal/src/Driver/PDO/Connection.php:33
/application/vendor/doctrine/dbal/src/Driver/Middleware/AbstractConnectionMiddleware.php:46
/application/vendor/doctrine/dbal/src/Logging/Connection.php:50
/application/vendor/doctrine/dbal/src/Driver/Middleware/AbstractConnectionMiddleware.php:46
/application/vendor/symfony/doctrine-bridge/Middleware/Debug/DBAL3/Connection.php:73
/application/vendor/sentry/sentry-symfony/src/Tracing/Doctrine/DBAL/TracingDriverConnectionForV2V3.php:127
/application/vendor/sentry/sentry-symfony/src/Tracing/Doctrine/DBAL/TracingDriverConnectionForV2V3.php:235
/application/vendor/sentry/sentry-symfony/src/Tracing/Doctrine/DBAL/TracingDriverConnectionForV2V3.php:126
/application/vendor/sentry/sentry-symfony/src/Tracing/Doctrine/DBAL/TracingServerInfoAwareDriverConnection.php:67
/application/vendor/doctrine/dbal/src/Connection.php:1211
/application/vendor/doctrine/dbal/src/Connection.php:1634
/application/vendor/doctrine/dbal/src/Connection.php:1531
/application/vendor/doctrine/orm/src/UnitOfWork.php:443
/application/vendor/doctrine/orm/src/EntityManager.php:259
/application/vendor/zenstruck/foundry/src/Proxy.php:180
/application/vendor/zenstruck/foundry/src/Factory.php:167
/application/vendor/zenstruck/foundry/src/Persistence/PersistentProxyObjectFactory.php:77
/application/src/Foundry/Story/AccesStory.php:15
/application/vendor/zenstruck/foundry/src/StoryManager.php:52
/application/vendor/zenstruck/foundry/src/Story.php:53
/application/vendor/zenstruck/foundry/src/Test/GlobalStateRegistry.php:58
/application/vendor/zenstruck/foundry/src/Test/TestState.php:216
/application/vendor/zenstruck/foundry/src/Test/DatabaseResetter.php:94
/application/vendor/zenstruck/foundry/src/Test/DatabaseResetter.php:50
/application/vendor/zenstruck/foundry/src/Test/ResetDatabase.php:56

[nikophil]

do you think you'll be able to create a reproducer in Foundry's tests? everything is here: we have global stories in these tests, and it uses Dama 8 and Symfony 7 (but we don't have this problem)

[Fabrn]

I don't really know... I might also try to create a project from scratch, with a simple entity, setup everything for testing, and see what happens. Who knows, maybe this comes from our database's configuration or version.

According to MySQL documentation, dropping database or truncating tables cause implicit commit. Isn't it that the database drop is included in the same transaction than the Story loading ? I might be saying stupid things here, I didn't explore how DAMA works for now.

[nikophil]

did you try to set your migration "not transactional"?
#538 (comment)

[Fabrn]

Well yes that's funny because that was a solution found for my own issue a few months ago and I don't know why I didn't connect them together. I confirm that doing so resolves this issue.

Sorry for the inconvenience had a rough day and I was stupid here.

Have a nice day 🙂

[nikophil]

no problem!
I'm closing the other issue as well