feat: add transactional to config to allow deactivation of transactions

[robinlehrmann]

Hi, when I try to use mariadb and the DoctrineDbalStore inside a doctrine migration, transactions are not working as expected.

For know I'm not 100% sure how to reproduce it. I only know that when I'm using the Event-Store Repository as part of a migration, the first run always ends up with an error like this:

[error] Migration App\MigrationsEventSourcing\Version20250527155847 failed during Execution. Error: "An exception occurred in the driver: There is no active transaction"

In ExceptionConverter.php line 91:

  An exception occurred in the driver: There is no active transaction


In Exception.php line 24:

  There is no active transaction


In Connection.php line 123:

  There is no active transaction


In ExceptionConverter.php line 91:

  An exception occurred while executing a query: SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist


In Exception.php line 24:

  SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist


In Connection.php line 27:

  SQLSTATE[42000]: Syntax error or access violation: 1305 SAVEPOINT DOCTRINE_2 does not exist

This PR allows to deactivate transactions via the config. (It's a first draft for now to start a discussion)

[DanielBadura]

I'm not sure if you should have this configureable. I mean, in special cases for it could be beneficial, but I don't know right now any. Do you have a opinion on that @DavidBadura ?

Netherless, the option key must be defined as nullable transactional?: bool and the code must account that the key does not exist to be BC compatible.

[DavidBadura]

I have thought about it a lot, and I am against adding this option to the store. The reason is that the API would then no longer do what it is supposed to. If the developer executes transactional, they're assuming it is also being executed in a transaction. With this option, that wouldn't be the case, which I think would be wrong. Otherwise, if you forget to turn off the option after the migration and then go into production, you could mess up your store.

I would not recommend using AggregateRepositories and Aggregates in the migration. Just as I would not recommend using Doctrine EntityManager and Entities in the migration. The reason is that the migration always breaks over time (because the code changes) and you always have to maintain the migration. And in this case, it interferes with other processes, like Transactions here.

I would create a CLI command that performs the migration or import of data from the old to the new system. This also gives you more power. And you can also use all the services there.

[DanielBadura]

@robinlehrmann did you had time to read @DavidBadura response here? And is this PR maybe also obsolete by using the config option described here patchlevel/event-sourcing-bundle#258?

[robinlehrmann]

@DanielBadura

did you had time to read @DavidBadura response here?

I just saw the answer.

@DavidBadura

I would not recommend using AggregateRepositories and Aggregates in the migration. Just as I would not recommend using Doctrine EntityManager and Entities in the migration. The reason is that the migration always breaks over time (because the code changes) and you always have to maintain the migration. And in this case, it interferes with other processes, like Transactions here.

I see. The usage of entities and aggregates as part of the migrations was since the beginning not the best option. I agree with you and will create a CLI command for that.

This MR can be closed then.

Thanks in advance!