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 <gojeta...@gmail.com> 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.
