Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement SAVEPOINT (and friends.) #575

Open
jonathanstowe opened this issue Apr 13, 2024 · 3 comments
Open

Implement SAVEPOINT (and friends.) #575

jonathanstowe opened this issue Apr 13, 2024 · 3 comments

Comments

@jonathanstowe
Copy link
Contributor

There are still some outstanding infelicities with transactions (such as e.g #507 ) particularly with the way that inner hidden transactions are dealt with by creating a new connection that still may lead to unexpected behaviour (largely because changes in the outer transaction will be isolated from those in the inner one.)

Implementing 'SAVEPOINT' (and ROLLBACK TO SAVEPOINT, COMMIT SAVEPOINT and RELEASE SAVEPOINT,) would go some way to addressing this: it would no longer be necessary to create a new connection to deal with the inner transactions, rather it would be possible to implicitly translate any nested BEGIN -> COMMIT/ROLLBACK to use the savepoint equivalents instead.

It may even simplify a solution to the #507: the driver will maintain a list of the savepoints each with their own Promise, the rollback, commit or release of the savepoint will keep the promise and the outer commit or rollback will wait on the promises before issuing the commit or rollback to the engine.

Savepoints are widely implemented, there are some small difference but they are trivially dealt in the drivers:

https://www.postgresql.org/docs/current/sql-savepoint.html
https://dev.mysql.com/doc/refman/8.0/en/savepoint.html
https://www.sqlite.org/lang_savepoint.html

@jonathanstowe
Copy link
Contributor Author

@jonathanstowe
Copy link
Contributor Author

FWIW another motivation for this is that I have a possible need for an extension of Test::Class whereby each test method is wrapped in a transaction that will always rollback when done, as it currently stands this can't work with nested transactions being in a separate connection.

@FCO
Copy link
Owner

FCO commented Apr 15, 2024

That sounds great!

I'm not sure when I'll be able to work on that, but I totally agree that's a great solution!

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants