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 ORM first check using param then fallback to router and then ultimately fallback to default. I guess we can do same thing for transaction too. I dont know completely about django standers but by this it will be backward compatible (issues mentioned in previous messages of ignoring using and other stuff is removed) and the overhead of unnecessary passing using in each transaction api can be avoided (not to mention about the issues we face when some miss it and code breaks). About the point of maintenance, testing etc etc, in my opinion that is part of life and we cannot avoid it. He may not be asking to release it immediately/in separate release, rather you can take this minor enhance with other release and manage your testing and all. On Thursday, June 3, 2021 at 5:04:48 PM UTC+5:30 Aymeric Augustin wrote: > On 3 Jun 2021, at 12:03, N Aditya <gojeta...@gmail.com> 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 being > queried and it's often useful to do so. So Django supports it. > > It would be convenient to do the same for transaction blocks, but it isn't > possible in a generally useful way because you don't know yet which models > will be queried. So Django doesn't support it. > > 2. Also generally speaking, was the intention of building the routers > framework only to allow routing based on models and other hints available > as part of the args list > > > Yes, it was. > > or to expose hooks that can achieve routing of DB queries based on custom > logic that could either depend on the args list or not (The use-cases are > plenty. It can be from some state being pushed into a KV store based on > some logic that gets executed in the view etc., not just thread-local > state. Also, considering thread-local state here to be globals seems > completely unfair since in actuality, it is tied to the request's scope and > not global for all requests). > > > No, it wasn't. > > Also, if possible, I'd like to hear opinions about the above from the > authors of the routers framework as well. > > > You could read what Russell wrote at that time: > > > https://github.com/django/django/commit/1b3dc8ad9a28486542f766ff93318aa6b4f5999b > https://code.djangoproject.com/ticket/12540 > https://code.djangoproject.com/ticket/12541 > > > Also, I believe you quoted this in your previous message: > > > Indeed, you'd need something slightly smarter, but since connections are > thread-local in Django, it should be manageable. > > (...) > > > Let's say my proposal doesn't work, then. I didn't try it! > > -- > Aymeric. > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/037dadcc-9193-4c23-bcd6-3b4582548a0en%40googlegroups.com.
