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 it return a different value at different times would be to depend on global variables. This is bad software engineering. It doesn't meet Django's standards. I believe the final suggestion you made was as follows: > 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 officially supported, but this looks like the closest option to the intent you expressed. 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 ? If so, why suggest something which you consider bad practise ? 2. 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 ? 3. 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) Based on your suggestions, I haven't arrived at a soln which can make this work. > Just because something is easy to implement doesn't mean it gets added to Django I missed to type in a couple of words which has created quite the spur around this. My apologies for that. What I really wanted to key in was this: > I don't see any reason for why providing a hook seems so difficult *to implement*. I guess we all agreed on the fact that this would be fairly easy to implement. But I never implied/wanted to imply anything about adding this to Django just because the implementation was fairly easy. Also, you quoted in your previous message: > It also needs to be generally useful and well designed. Your proposal doesn't meet the second criterion and I'm skeptical about the first one. I believe I've fairly stated my use-case. If you're stating that the proposal is not `generally useful` then I believe you're implying that routing of DB queries based on request metadata like domain, IP, location etc., may not be useful to most folks. I'm skeptical about this. Also, regd the `well designed` part, I believe we haven't arrived at a clean solution based on your recommendations either. So I believe we'll have to get this sorted. Also, you quoted: > Four committers rejected your proposal and suggested alternatives I don't think that apart from your suggestion, the other folks mentioned anything concrete along the lines of a work around. Let me know if I'm missing something here. To summarise, I've been trying to help from my end as well to try and make ends meet. I love using Django and I respect a lot of its design philosophies. I would like to be a contributor in the long run and do some exciting work. Let me knw how we can take this forward in the best possible way. Regards, Aditya N On Wednesday, June 2, 2021 at 2:02:35 AM UTC+5:30 Aymeric Augustin wrote: > Hello, > > On 1 Jun 2021, at 14:35, N Aditya <gojeta...@gmail.com> 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 gets added to > Django. It also needs to be generally useful and well designed. Your > proposal doesn't meet the second criterion and I'm skeptical about the > first one. > > Indeed, the get_connection() API you're proposing doesn't take any > argument. As a consequence, the only way to make it return a different > value at different times would be to depend on global variables. This is > bad software engineering. It doesn't meet Django's standards. > > (If you don't know why having functions that return different values based > on global variables is a bad idea, you can search for "global state" in > your favorite search engine. I'm pretty sure you can find a good blog post > explaining why. And yes Django suffers from some legacy in this area. We > are trying to avoid taking more debt.) > > Four committers rejected your proposal and suggested alternatives. We're > trying to help. Pushing the same idea again won't work any better. Please > take into account the objections and try to find a design that addresses > them, or implement one of the alternatives we offered. > > Thank you, > > -- > 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/62843632-f892-4992-ad95-262e4e27bd5fn%40googlegroups.com.
