-
Notifications
You must be signed in to change notification settings - Fork 38
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
Enable nested transactions and rollbacks? #56
Comments
While at it, maybe we can also add some locking with an MVar, so that another thread that happens to have the same connexion does not interfere with a transaction… There is some conversation about it up the stream: lpsmith/postgresql-simple#202 — but it is inconclusive and we are in a better position to do this since we are high level and already carry around an environment. |
My rough idea for this library was that it would live at a lower level of abstraction than what you're talking about. Now it is true that this package has a few |
Sure, if this does not align with your vision, I can find a way to handle it independently. |
So, I drafted a proof of concept and it is actually very simple.There are no
I think it would be problematic to implement this on top of
|
So, SQL has two features that essentially do the same thing. First you have to use
begin … rollback / commit
, and then inside it you can usesavepoint … rollback to savepoint / release savepoint
, and you can do that any number of times, effectively creating arbitrary nesting of transactions.This means that in principle transactions compose. But at present, if I wrap a snaplet that uses a transaction into another snaplet that also uses a transaction, it will be a mess: the transaction will start at the first
begin
, the innerbegin
will be ignored, then the innerrollback / commit
will affect everything back to the firstbegin
and the finalrollback / commit
will be ignored. Good for me that PostgreSQL emits a warning in such cases!This is not in principle a problem — we only need to track in the
HasPostgres
monad what the current nesting level is. Then we can intelligently choose whether to usebegin
orsavepoint
. For bonus points, we may also carry around a source of fresh names for save points — this would be required for vanilla SQL, but PostgreSQL allows using the same name for nested save points, so it is not necessary.Can we have this feature? I am considering writing it for a private project and if it goes well I may be able to contribute a patch.
The text was updated successfully, but these errors were encountered: