Closed RudolfMan closed 2 years ago
I would say both situations can be desired. For example, if I am unaware I am calling something that has a inner transaction, I would be very surprised if that affects the result of my transaction. Especially because it is a non-local return happening as a side effect. By manually cascading you at least have direct control over how this happens.
It seemed not obvious to me why transactions are flattened, but the rollback value is not. Is that on purpose?
Surely, currently we can check on return value of inner transaction and propagate it manually if needed, but I was expecting to see
{:error, :foo}
since, that was the reason of rolling back the transaction. And probably consider:rollback
as default/generic reason.In my case I have a function that in transaction calls another function that also runs in transaction. I rely on return from
transaction
, either "ok" or "error" tuple with potentially my custom error reasonAnd when I call
foo
one of the expected returns would be{:error, :bar_error}
I have put up together a naive change that propagates the rollback value if one doesn't exit.. (and also get's overriden by outer transaction's rollback, if any) https://github.com/rudolfman/db_connection/commit/8827a0db6e05f9db13ed5226b9d49d5efe82f0f7