Doing a transaction procedurally, instead of passing in a closure?

[vdods]

I've been using Connection::transaction, to which a closure is passed which comprises the body of the transaction. I'm finding it very hard to compose this with other functions that invoke DB statements. Is there a way to do this more like in plain SQL, where you issue a begin transaction statement, and later issue a commit statement? Perhaps the begin transaction would return a guard object that rolls back the transaction if commit isn't called.

I see TransactionManager trait and AnsiTransactionManager, and it looks like this is meant to be an internal impl detail of Connection, but it also seems like the most promising way to do this sort of procedural transaction invocation. Am I on the right track? Has anyone already done what I'm describing?

[weiznich]

We do not really support any other variant to execute transactions via our public API as there is too much that could go wrong with the other approaches. Using a guard object would cause issues if the rollback fails due to whatever reasons as we cannot return any result from the destructor.
TransactionManager is more or less considered to be a building block for third party connection implementations rather than something that should be used in ordinary applications.

That all written I would be interested to know in which cases you feel that the current Connection::transaction function does not work well. Could you provide an concrete example for this?

[Alvenix]

So based on your previous description that would cause a panic as soon as either the load, the process_user or the execute function call returned an error, because that will drop the transaction guard that contains an uncommitted transaction. Now you could argue that you would need to rollback the transaction on drop instead of panicing, but that raises concerns about error handling for sync code. For async code that's just not possible because you cannot perform async actions in a sync drop impl (that' likely why SeaORM panics in that case).

I meant that seaorm attempt rollback and panic on rollback failure. Sorry for not being clear.

Thank you for the detailed response.

Both suggestions seem good, using function instead of closures is a good alternative that I did not think deeply about, it may simplify the code a lot. I may try to create transaction guard via extension trait later. I love that rust support adding method to existing structs via traits, I kinda forget that sometimes.

[ColonelThirtyTwo]

I'll point out that one advantage to guard objects over a closure is that closures interfere with flow control. Using break, continue, and return are natural with a guard object, but require workarounds with a closure. And it's impossible to await inside of the closure for diesel's transactions (not that awaiting with a transaction open is a great idea, but there may be a use case for it).

[weiznich]

I'll point out that one advantage to guard objects over a closure is that closures interfere with flow control. Using break, continue, and return are natural with a guard object, but require workarounds with a closure. And it's impossible to await inside of the closure for diesel's transactions (not that awaiting with a transaction open is a great idea, but there may be a use case for it).

At least for me that's more an advantage of the closure based approach. In all listed cases you either want to be explicit about what happens with your transaction (break, continue, return) or you want to prevent that at all (await). A drop guard based approach cannot guarantee that.

[cylewitruk]

I can chime in and give one useful example, anyway - I'm trying to retrofit Diesel into a large, older codebase which uses rusqlite and a lot of tx handles passed around in their own handle objects which are used to synchronize commit/rollback between multiple types of datastores (it's a blockchain, so the on-disk merkleized representation and the metadata stored in sqlite).

Having an opt-in "procedural-tx" feature or something that would expose the TransactionManager from a Connection would have been really helpful here, as the changes become much more extensive and risky when also having to try to change the functionality of the code at the same time as trying to convert to Diesel.

I found https://github.com/DR-BoneZ/diesel-transaction-handles-rs which is a nice idea which I might adapt, but I would have preferred to avoid the overhead :)

[weiznich]

Having an opt-in "procedural-tx" feature or something that would expose the TransactionManager from a Connection would have been really helpful here, as the changes become much more extensive and risky when also having to try to change the functionality of the code at the same time as trying to convert to Diesel.

That's already possible as the TransactionManager type is already exposed: https://docs.diesel.rs/2.1.x/diesel/connection/trait.Connection.html#associatedtype.TransactionManager. You can also access the actual transaction manager implementation via AnsiTransactionManager: https://docs.diesel.rs/2.1.x/diesel/connection/struct.AnsiTransactionManager.html