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 framework only to allow routing based on models and other hints available as part of the args list 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). i. If your answer is the former, then you guys should strongly re-consider the design since they can easily be perceived and used as hooks to achieve the latter. I would end my discussion here. ii. If your answer is the latter, then I'm looking for a similar hook for the transaction APIs as well. I would want to continue the discussion here. Also, if possible, I'd like to hear opinions about the above from the authors of the routers framework as well. --- 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. Using some kind of thread sync primitive like a Lock/Semaphore at the middleware level to achieve this with stability doesn't seem manageable. It's just bad. Also, if for some reason within the view, the connection gets broken and I try to re-establish it, I have no guarantees as to what settings.databases["default"] might look like at that point and so I'll have to fetch the config that was used to initially create the connection from somewhere and then re-establish it again using a thread-sync primitive. I'm not even going to talk about the repercussions of using this approach with a ThreadPoolExecutor/ProcessPoolExecutor from within a view. Regards, Aditya N On Thursday, June 3, 2021 at 2:48:27 AM UTC+5:30 Aymeric Augustin wrote: > On 2 Jun 2021, at 07:49, N Aditya wrote: > > Below are a few things I'd like to clarify: > >1. Are you referring to thread-locals as `global state/variables` in >your previous message ? > > Yes. > > >1. If so, why suggest something which you consider bad practise ? > > You rejected the good practice before — atomic(using=...) so I'm looking > for something that matches your constraint. > > >1. As a consequence, if using thread-locals is considered bad software >engg, could you please give me a way by which I could pass on request >metadata to the router layer cleanly ? > > Pass it explicitly with `atomic(using=...)`. I'm aware that it doesn't > work for third-party libraries that you don't control. I don't have a > perfect solution. > > >1. The final recommendation you gave is something that isn't >officially supported and *would fail when a threaded server or a fully >async request path* is used. >(Even your favourite search engine might not be of much help here) > > Indeed, you'd need something slightly smarter, but since connections are > thread-local in Django, it should be manageable. > > I don't think you can meaningfully put "fully async request path" and > "database transaction managed by the Django ORM" in the same sentence. > You'd run the transaction in a thread pool, which brings you back to by > previous case. > > -- > 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/c63dc1ca-188c-48ff-aeb7-3a6ce8fedbe6n%40googlegroups.com.
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 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/35082C11-6797-43D9-9951-DC4935DEE62C%40polytechnique.org.
Changing widget rendering templates
Hey all, I've been looking at the couple of tickets open to improve accessibility of the forms and checkbox/radio widgets. [1][2] While changing the layout is _fairly_ straight forward I'm unsure how to transition to the new way. I'm focusing this change in changing the widget templates until the patch for template based rendering of forms is merged. I think the options are: 1) Just make the change and have a breaking change. 😬 2) Introduce the new template and deprecate use of the old template. This is really horrid as _everyone_ will have to add boiler plate template over rides to point at the new template. We'd then probably want to change the name again at the end of the depreciation period. 3) Change the default template and package the old template, folk can then over ride their template if they still want the old behaviour. We can then deprecate the old template, and folk can include it their selves if they want it longer term. While a breaking change there would be a _simple_ solution. I hope this is enough to get your creative juices going! I'm hoping there is a better way than what I can think of. My gut reaction would be to go for option 3. We don't have any data on how well used the default templates are used, I'm guessing it's not used that much... Appreciate your thoughts. Kind Regards David [1]https://code.djangoproject.com/ticket/32338 [2]https://code.djangoproject.com/ticket/32339 -- 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/0f1b752b-fd69-4d22-939e-867cc17e7819n%40googlegroups.com.
