Re: Transaction APIs do not consult the DB router to choose DB connection

Hi , I guess I was facing similar issue like Aditya and while searching landed on this page. By following that is available to us (passing using in transaction apis and router for ORM) definitely we got the results we were expecting but my point is overhead of writing it. In my understanding

Re: Transaction APIs do not consult the DB router to choose DB connection

> On 3 Jun 2021, at 12:03, N Aditya wrote: > > 1. If atomic(using=...) is the way to go and the same has been implemented > for ORM queries as well, why introduce something like the routers framework > in the first place ? You can meaningfully route individual ORM queries based on the model be

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Augustin, I'd like to clarify a few things: 1. If atomic(using=...) is the way to go and the same has been implemented for ORM queries as well, why introduce something like the routers framework in the first place ? 2. Also generally speaking, was the intention of building the routers fr

Re: Transaction APIs do not consult the DB router to choose DB connection

> On 2 Jun 2021, at 07:49, N Aditya wrote: > > Below are a few things I'd like to clarify: > Are you referring to thread-locals as `global state/variables` in your > previous message ? Yes. > If so, why suggest something which you consider bad practise ? You rejected the good practice before — a

Re: Transaction APIs do not consult the DB router to choose DB connection

Hi Aditya, I think the basic issue is that the DB Routers framework is not the right tool for the task you have in mind. You are trying to redirect all database activity according to request parameters. The routers are built for specific uses, and -- by design -- they don't cover all cases; it's n

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Augustin, Just to clarify, from before, you quoted: > you can store the current HTTP request as a thread-local variable in your application and access it from anywhere, for example from a database router. Also, from your previous message, you quoted > As a consequence, the only way to make i

Re: Transaction APIs do not consult the DB router to choose DB connection

Hello, > On 1 Jun 2021, at 14:35, N Aditya wrote: > > All I'm looking for is a hook that the transaction APIs can call before > deciding on which database to use. I don't see any reason for why providing a > hook seems so difficult. Just because something is easy to implement doesn't mean it

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Lokesh, Just out of curiosity, I'd like to clarify the expected behaviour. If a db_for_transaction method is implemented, I believe it would be consulted for transaction APIs like atomic etc., Reads and writes which happen within that transaction are nevertheless going to consult their r

Re: Transaction APIs do not consult the DB router to choose DB connection

Hi Everyone, Our use case is that we have a writer primary database and read-only replica databases. The replicas can sometimes be a bit behind the primary We have written a Router like this class CustomRouter: def db_for_read(self, model, **hints): return 'reader' def db_for_wr

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Florian, I'd like to point out that the code snippet which I wrote is just a scratch version of how it might look. I'd first like to reach consensus on the idea itself before writing something concrete. Obviously it wouldn't be as naive as overriding something that the user provided expli

Re: Transaction APIs do not consult the DB router to choose DB connection

On Tuesday, June 1, 2021 at 2:35:17 PM UTC+2 gojeta...@gmail.com wrote: > I don't see any reason for why providing a hook seems so difficult. > It is more code to maintain, needs tests etc and increases complexity. Just because something is easy on the surface, doesn't mean it will be easy in

Re: Transaction APIs do not consult the DB router to choose DB connection

On Tuesday, June 1, 2021 at 1:45:29 PM UTC+2 Aymeric Augustin wrote: > I would recommend running without persistent database connections > (CONN_MAX_AGE = 0) and switching settings.DATABASE["default"] in a > middleware at the beginning of every request. Modifying settings at runtime > isn't off

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey, I agree to the fact that the request object being passed to the DB layer (routers/transaction APIs) may not be pragmatic according to the Loose coupling approach. Quoting what you said: > you can store the current HTTP request as a thread-local variable in your application and access i

Re: Transaction APIs do not consult the DB router to choose DB connection

Hello, The first item in Django's design philosophies is Loose coupling . Per this principle, the database layer shouldn't know about the HTTP layer. This is a strong reason for keeping the HTTP request object aw

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey all, I believe there's a major misunderstanding of what I've been trying to convey. Let me rephrase: *Problem*: Include the request object as a decision param in the routers framework/transaction APIs based on which a DB can be chosen i.e all queries(reads/writes) and transactions are directe

Re: Transaction APIs do not consult the DB router to choose DB connection

On Monday, May 31, 2021 at 12:13:58 PM UTC+2 Adam Johnson wrote: > I'm also -1 on changing anything in Django right now. > -1 as well, I simply see no way how something like: ``` with transaction.atomic(): Model1.objects.create() Model2.objects.create() ``` will allow for any useful

Re: Transaction APIs do not consult the DB router to choose DB connection

I'm also -1 on changing anything in Django right now. I think we should indeed take the "default position" for complex features: write a third party library, get some traction. If many people find it useful, we can look at adding something to core. It sounds like you're already working on such a l

Re: Transaction APIs do not consult the DB router to choose DB connection

Aditya, > "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. Atomic doesn't consult it directly but the ORM does before interacting with transactions. Wh

Re: Transaction APIs do not consult the DB router to choose DB connection

Hey Adam/Simon, How can we take this forward ? Regards, Aditya N On Friday, May 28, 2021 at 3:04:14 PM UTC+5:30 N Aditya wrote: > 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 u

Re: Transaction APIs do not consult the DB router to choose DB connection

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

Re: Transaction APIs do not consult the DB router to choose DB connection

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 need

Re: Transaction APIs do not consult the DB router to choose DB connection

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 resu

Re: Transaction APIs do not consult the DB router to choose DB connection

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 he

Re: Transaction APIs do not consult the DB router to choose DB connection

Ticket that directed to the mailing list for wider feedback https://code.djangoproject.com/ticket/32788 --- Can you think of places where this db_for_transaction hook would differ in any way from what db_for_write returns? That's what Django uses internally in such instances 1. ​ https

Transaction APIs do not consult the DB router to choose DB connection

>From the Django docs, for any ORM query made, the DB alias to use is determined by the following rules: - Checks if the using keyword is used either as a parameter in the function call or chained with QuerySet. - Consults the DB routers in order until a match is found. - Falls bac