Hi, I'm intrigued in helping develop the async ORM engines (link to random PR <https://github.com/django/django/pull/15357> with aiosqlite and base async engine). The biggest road block is having test cases for async engines only; for instance, introspection/test_async.py can't run because the test suite needs to first migrate using a sync engine as the default database connection then switch the default alias to using an async engine; additionally, for most of the test suite, it uses the sync engine. The current methods I'm thinking of:
1. Each async engine would get its own CI worker. I think it's a waste of resources and because it wouldn't help Django users who also need to write test cases with both an async and sync (for migrations) engine. 2. Async and sync engines for the same database are run at the same time. Every async engine requires a parallel sync engine, an alias to be specified in the engine's DATABASES options. This way, while testing, migrations can be performed with a designated sync engine. This is great for the end user who may be async-centric; this doesn't really resolve the current problem. Most of the Django test suite is designed for synchronous db engines, so the default alias database engine will switch around a bunch of times. 3. Implement a test decorator that switches the default alias connection. Lemme know if that's confusing. Thanks, 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 django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4ca69f37-cc9e-40c3-a73b-cc9a125ebaecn%40googlegroups.com.
