> Slightly off-topic but once we have an async ORM, making it synchronous is not impossible (I believe either Channels or Daphne already have shims that use a worker thread to spin the event loop until a future is fulfilled).
This is in fact the proposed way to make the ORM work with both sync and async worlds once the interior is fully-async. > In one project I really enjoyed using channels just as a background worker instead of celery, and the DEP does not talk much in the Email section: use the async variant, can be tackled separately, low priority. > > For now the ORM works, but if sending an email fails (ie. SMTP down) it will raise an exception that can end up in a 500 error, it would be great if Django could retry so that emails leave when its SMTP is up again, would that maybe weight in priority ? If you want guaranteed email delivery, that's a task for something like Celery or a third-party API; any method of sending emails in the background in the same process, be it threads or async coroutines, is going to be unreliable as the server may die any time. I don't think it's sensible for Django to try and solve this problem internally, at least not as part of this async push. Andrew On Thu, May 9, 2019 at 12:56 PM Patryk Zawadzki <pat...@gmail.com> wrote: > That said, I also think it's important to allow the ORM to support both >> modes in the long term. I truly believe the best way to be able to write >> async code is to _have the choice to write it_, rather than being made to >> all the time; if we make people use a separate, async ORM, then we force >> them to write every view asynchronously, with all the extra danger and >> thinking that requires. It's much better for Django to do the hard work, >> and say "hey, if you want to write asynchronously or synchronously, that's >> fine - it takes literally zero extra effort to go either way". >> > > Slightly off-topic but once we have an async ORM, making it synchronous is > not impossible (I believe either Channels or Daphne already have shims that > use a worker thread to spin the event loop until a future is fulfilled). > > -- > 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 post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/402dbe77-44fc-485b-b058-e619a1576ddb%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/402dbe77-44fc-485b-b058-e619a1576ddb%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAFwN1urOnhEJDb6Sm45U59iF5hCZmN%3Dw-J%2B0er4UCnqh3qsmCw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.