Savepoint support for Transaction

[kaol]

As it stands, hasql supports performing transactions that end either in a rollback or a commit. Would you consider adding a third option, namely savepoints? That would allow for sane transaction isolation while letting interleaving IO in between. That is, perform this operation at the end of Hasql.Transaction.run: http://www.postgresql.org/docs/current/static/sql-savepoint.html

Then, when you continue the transaction starting from that savepoint, you'd perform a rollback to savepoint instead of an abort, if need be.

run would need to have a type like

run :: Transaction a -> ... -> IO (Either Query.ResultsError (Either (SavePoint a) a))

and Transaction should have operations for ending the transaction with a savepoint instead of a return, and for rolling back to a specific savepoint instead of just the latest one. Continuing the transaction would involve a version of run that would take the savepoint instead of the isolation, mode and connection parameters.

I'm not certain how all the kinks of an API with savepoints would go. I may try to sketch an implementation myself, yet. I'll need to familiarize myself with the new hasql version first. But I'd love to hear first whether this kind of functionality would be anything you'd care to see in hasql. I like the purity of leaving IO out of SQL transactions but I feel that there's a way to have my cake and eat it too.

[nikita-volkov]

It is basically a different abstraction that you're talking about. You need different properties from it and expect a bit different behaviour. Hence it simply makes a perfect case for releasing a different package, and it's great, because one of my primary intents with this giant restructuring of the ecosystem was to make it extendable.

This is why my interpretation of the transaction with the accent on the purity and STM-inspired behaviour is released only as an extension-package. It's done so intentionally, with one of the reasons being to allow alternative interpretations like yours to be released as well and compete with equal status, instead of us having endless debates about which interpretation is better.

IOW just go ahead and release a package with your view on transactions, and good luck!

[kaol]

An update of sorts for this. I don't even know myself now if I even wanted to mix savepoints to this, and upon further reading, I saw that they don't really offer help with serialization conflicts.

But I've got started with coding with the new API version and I like getting access to making queries without necessarily having to have them be whole transactions. For anyone curious about it, I've made some code for snap to use hasql with it, and for authenticating and getting user's data.