On 20/09/2019 08:49, Peter Bex wrote:
> On Fri, Sep 20, 2019 at 12:14:37AM +0300, Lassi Kortela wrote:
>> If you live and breathe databases this is probably a non-issue, but for us
>> plebs, a typical SQL database looks a bit like Howl's Moving Castle.
>
> Haha, I love that analogy.
>
>>>> You might be inside transactions on two connections at the same time, as when you are copying data from one db to another.
>>
>> Wow, that is true! So transactions need to have labels. Perhaps be passed as
>> lambda arguments to be bound to variables.
>
> I don't really see why that's necessary.  just accept the database
> connection as an argument and roll back the current deepest transaction
> inside that database.  You might not even want to roll back the other
> connection's transaction!  (think, for example, about logging attempts
> made to update db1, and logging failure in db2).

Yep.

Or, for an alternative approach, make with-transaction pass a rollback
closure thunk to the closure it invokes as the transaction body.

> I'm not sure exactly what a rollback call ought to do though after
> aborting the transaction; should it invoke the continuation of the
> closest with-transaction block?  Then perhaps the rollback procedure
> should also accept the value(s) to pass to said continuation as rest
> args:  (rollback! db return-value1 ...)
>
> Just continuing with the regular flow seems unwise to me, as those
> statements would then be taking place in the parent transaction.

Yeah. The only problem with (rollback) escaping to with-transaction is
that it would make any cleanup actions you want to perform AFTER the
rollback trickier to fit in... but I can't think of why I'd want that
off the top of my head.

>
> Cheers,
> Peter
>


--
Alaric Snell-Pym   (M7KIT)
http://www.snell-pym.org.uk/alaric/