Hi internals,
Since PHP 8.0, PDO fully supports MySQL transactions -- this means that
inTransaction() will report the actual connection transaction state, as
opposed to an emulated (incorrect) transaction state tracked by PDO itself.
This has two primary effects: PDO is aware of transactions crea
On 12-04-2021 14:07, Nikita Popov wrote:
> I believe this behavior is correct, but I could see an argument made in
> favor of always allowing commit() calls (but not rollBack() calls) even if
> there is no active transaction. That would change the meaning of commit()
> from "commit an active transa
What would be a benefit of a commit function that can be executed without
an active transaction?
>
>
> I think it is really nice that commit() throws for inactive
> transactions. Code paths that mess up your transactions will not go
> unnoticed that easily.
>
+1. I've always found this behaviour in MySQL very surprising and error
prone (BEGIN; BEGIN; COMMIT; COMMIT; => no errors), and I'm act
Hi Nikita,
On 12/04/2021 14:07, Nikita Popov wrote:
$pdo->beginTransaction()
$pdo->exec('DROP TABLE foobar'); // Implicitly commits transaction
$pdo->exec('DROP TABLE barfoo'); // Transaction not active anymore
$pdo->commit(); // Throws because no transaction active
now throws an exception, bec
Good example of why commit() should throw an exception, I think - it's just
alerted the developer that executing their previous statement has caused an
implicit commit. Imagine if they had a complex sequence of queries and
didn't realise they'd added one which ended the transaction, thinking they
c
