Hello, I’ll try to clarify what I said in the PR below..
The main reason for the `--parallel` option was to make Django’s own test suite faster. A full run went down from ~8m to ~1m30 when I committed that patch, which really helps the development cycle on invasive patches. Since Django’s own test runner bypasses migrations, whenever you make changes to a model in Django’s test suite, you need a run without `--keepdb`. So the problem you’re describing doesn’t exist for the primary use case. Now let’s talk about models and migrations in users’ projects, which is the logical next step and the use case you’re trying to improve. Note that the `--parallel` option is experimental and often non-functional in this context: as soon as two tests hit a resource other than the database — say, the cache — they can stomp upon one another. > On 05 Jul 2016, at 00:22, Romain Garrigues <[email protected]> > wrote: > > We could have just documented this limitation, but I don't think that my > situation is a really rare edge case in terms of process, so I was suggesting > to add a new option to be able to reset the cloned databases if needed (let's > name it --parallel-clone-reset). When I make changes to models, usually I keep removing and recreating a single migration, which is incompatible with using the `--keepdb` option. Whenever I make changes, I run without `--keepdb` once. > I don't really like the idea of adding a new option, as it impacts the test > runner, the clone_test_db function signature, ... but I have not found a > better idea to at the same time keep the performances with --keepdb and > --parallel, and handle these newly added migrations to a project. I’m not a fan of a new option either… > To summarize my proposal, this option (--parallel-clone-reset, or any other > name) should be used only if you are using --keepdb and --parallel options at > the same time, and when you have added a new migration between 2 test run. IIRC this will more than double the run time of Django’s own test suite on MySQL: it will increase from ~2m to ~4m (give or take 30s) because cloning databases is slow on MySQL. I’m quoting all these figures from memory and I may mix them up. As I said on the ticket it would be useful to redo the benchmark on a first run and subsequent run of `./runtests.py` on PostgreSQL and MySQL. You could argue that it’s best to degrade the experience of a few Django contributors (original use case, Django’s test suite) for the benefits of the wider community (new use case, projects’ test suites). However the original use case is known to work and I don’t believe that the new use case works well enough in general, at least not without some engineering to isolate tests from one another. For this reason I’m not convinced by this argument. I hope this clarifies the context of the trade-off we’re discussing. Best regards, -- 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 [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/BD5FB0D4-C9E1-4681-A5A1-CCD6D6BB84B7%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
