> On 2 Jun 2021, at 07:49, N Aditya <gojeta.adi...@gmail.com> 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 — atomic(using=...) so I'm looking for 
something that matches your constraint.
> 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.
> 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/37A77A89-74F1-498D-AE41-9772528E4E32%40polytechnique.org.

Reply via email to