Hey Adam,
Also, after giving it a bit of thought, I figured that integrating this
logic with the routers framework isn't entirely necessary.
So I came up with another perspective to the solution as well which I've
illustrated in message-3 of this thread.
Both approaches work for me.
Let me
Hey Adam,
"atomic does already call DB routers" -> Firstly after reading code, I
don't think the transaction APIs consult the routers. Secondly, I think I
already answered it in the initial discussion.
FYI from message-1:
1. Having a separate method for transaction is good because it
Aditya - you didn't answer Simon's first question: "Can you think of places
where this db_for_transaction hook would differ in any way from what
db_for_write returns?" I think this is the crux of the issue. atomic does
already call DB routers - in what case could you need to return a different
Hey Simon,
It would be possible to write a method as you've suggested above. But it
entails the following problems:
1. There would have to be a wrapper for each of the transaction APIs, not
just transaction.atomic since all of them take the using kwarg.
2. I'm trying to build a library that
