On Thursday, 17 June 2021 at 20:59:06 UTC, Steven Schveighoffer wrote:

[...]

>> Why don't you make the COMMIT explicit (by implementing commit method) and let the destructor ROLLBACK the transactino unconditionally?
>
> Yeah, that's possible, but then I still have to do:
>
> auto txn = conn.beginTransaction;
> scope(success) txn.commit;
>
> In which the `commit` call only does something on the outer-most txn.
>
> Not much better. And a bit awkward.

You have nested transactions txn1, ... txnN. Then there is a path thru the code having a line when all transactions are to be commited. Why don't you explicitly write

   tnxN.commit;
   :
   tnx1.commit;

or whatever the appropriate order is? Why do you hide the commit (side effect!) in a scope exit?

On 6/17/21 5:51 PM, kdevel wrote:
> On Thursday, 17 June 2021 at 20:59:06 UTC, Steven Schveighoffer wrote:
> 
> [...]
> 
>>> Why don't you make the COMMIT explicit (by implementing commit method) and let the destructor ROLLBACK the transactino unconditionally?
>>
>> Yeah, that's possible, but then I still have to do:
>>
>> auto txn = conn.beginTransaction;
>> scope(success) txn.commit;
>>
>> In which the `commit` call only does something on the outer-most txn.
>>
>> Not much better. And a bit awkward.
> 
> You have nested transactions txn1, ... txnN. Then there is a path thru the code having a line when all transactions are to be commited. Why don't you explicitly write
> 
>     tnxN.commit;
>     :
>     tnx1.commit;
> 
> or whatever the appropriate order is? Why do you hide the commit (side effect!) in a scope exit?
> 
> 

Transactions don't nest (this is mysql). So calling "START TRANSACTION" actually commits any in-progress transaction.

This is why I need something like a counter, and I increment and decrement the counter instead of actually beginning and committing the transaction.

A transaction is an atomic change to the database. Let's say I have 2 library types that have a `saveToDB` function. Each of those might have multiple SQL statements they use, which I want to be atomic. But I also might want to save both of them at once and have *that* be atomic.

Right now, I just put the transactions at the highest level, and the types cannot enforce atomicity of their own storage.

Really, there are 2 problems here. One is that I want to avoid having to type out those 3 lines. The other is that I want to implement some sort of re-entrant transactions, which can be done already without language help.

But something like a `scope(failure) ~this()` mechanism might be useful for the first problem.

-Steve

On Friday, 18 June 2021 at 12:37:15 UTC, Steven Schveighoffer wrote:
[...]
> A transaction is an atomic change to the database. Let's say I have 2 library types that have a `saveToDB` function. Each of those might have multiple SQL statements they use, which I want to be atomic.

What do you want to be atomic? The collection of SQL statements or the individual SQL statements?

> But I also might want to save both of them at once and have *that* be atomic.

Okay, you cannot commit within your saveToDB method. So you must tell the computer when it should commit:

   obj1.saveToDB;
   obj2.saveToDB;
   tx.commit;

> Right now, I just put the transactions at the highest level, and the types cannot enforce atomicity of their own storage.

They can, but they cannot enforce "*that*" atomicity from obove.

> Really, there are 2 problems here. One is that I want to avoid having to type out those 3 lines.

??

> The other is that I want to implement some sort of re-entrant transactions, which can be done already without language help.
>
> But something like a `scope(failure) ~this()` mechanism might be useful for the first problem.

Sure.