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).

This is all highly dependent on the logic of the application.

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.

Cheers,
Peter