I think most of what you've laid out sounds great and that pursuing async Django is in the projects best interests. The sync to async and async to sync wrappers that have come out of channels give me much more confidence that this project is doable in a reasonable amount of time with backwards compatibility being preserved.
The only real concern I have at the moment is around your comments regarding on demand foreign key traversal. If existing code running synchronously is going to be impacted, that's going to be very difficult for a lot of people. If it's only asynchronous traversal that'll have issues, then I have no real concern, as on demand foreign key fetching is usually a bug anyway. Having a brief read through the psycopg asynchronous docs[0], it looks like a number of features will be impossible or troublesome to use, like transactions, executemany, and named cursors (.iterator() with server side cursors). We'd also need to investigate how pgbouncer would work in async mode, as most large sites using postgres are also using pgbouncer. I would expect support can only further improve, especially if there is a driver like django pushing. Fallback would just be to run inside a thread pool though, so it's not a blocker for the rest of the proposal. Very exciting times ahead! [0] http://initd.org/psycopg/docs/advanced.html#asynchronous-support On Monday, 4 June 2018 23:18:23 UTC+10, Andrew Godwin wrote: > > Hello everyone, > > For a while now I have been working on potential plans for making Django > async-capable, and I finally have a plan I am reasonably happy with and > which I think we can actually do. > > This proposed roadmap, in its great length, is here: > > https://www.aeracode.org/2018/06/04/django-async-roadmap/ > > I'd like to invite discussion on this potential plan - including: > > - Do we think async is worth going after? Note that this is just async > HTTP capability, not WebSockets (that would remain in Channels) > > - Can we do this in a reasonable timeframe? If not, is there a way around > that? > > - Are the proposed modifications to how Django runs sensible? > > - How should we fund this? > > There's many more potential questions, and I really would love feedback on > this. I'm personally pretty convinced that we can and should do this, but > this is a decision we cannot take lightly, and I would love to hear what > you have to say. > > Andrew > -- 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 [email protected]. To post to this group, send email to [email protected]. 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/d3b3c04e-9db1-4a41-af3a-ad50209a07e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
