Hey Andrew, Great work on the DEP, the task at hand is humongous.
Do you think it's worth it to try and make the ORM async? It contains tons of magic that is inherently incompatible with explicit I/O that is required for async/await to work, things like silently fetching relations on first access, silently fetching deferred fields, queryset laziness etc. Those need to be explicitly awaited now and having to await regular field access for the sake of making deferred fields work is (I believe) not worth it. Conveniently, all of these magic properties are things that silently break performance of applications leading to the n+1 queries problem so I'm more than happy to get rid of them ;) Seeing that we can't get rid of anything in the old synchronous ORM, one idea would be to just depend on a separate, asyncio-based ORM and configure it to use the same tables and relations that the old ORM uses. It could work like model forms or formset factories, give it a "classic" model class, a list of overrides (we can't hope to automatically match old field types to anything understood by another engine) and receive an asyncio-capable table. There's an obvious candidate that Tom Christie is working on. We could even improve the querying syntax to use the SQL Alchemy's filtering operators with the hope of eventually reaching full static type safety[2] (one can only dream). The new ORM would only be usable in new async views and other features could be implemented gradually. You don't need to async forms (but with Tom Christie's typesystem[3] you don't really need async forms) and async template loading to achieve great things. You can already use things like requests-async[4] to access external resources, you can use libraries like Ariadne[5] to implement a GraphQL API with WebSocket-based subscriptions without having any of those (disclaimer: I work on Ariadne). It's okay if some things can't be ported initially or if certain features are only available in their sync flavor. The community will pave the way and provide many missing pieces before we get to implementing them. It's okay if new async counterparts have different APIs if these APIs are either better or are a closer match to how async/await works. [1] https://github.com/encode/orm [2] https://docs.sqlalchemy.org/en/13/core/tutorial.html#operators [3] https://github.com/encode/typesystem [4] https://github.com/encode/requests-async [5] https://github.com/mirumee/ariadne PS: If Django provided abstractions for common event loop operations such as "await this collections of futures" and "ensure this task is executed even if not explicitly awaited" then I think it may be possible to avoid explicitly depending on asyncio. All the best -- 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/da0d4c65-562b-44cc-abe0-e5c31e28d91d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
