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
Hi,
it might be a shot in the dark, but can't we check if Django's
testrunner applied new migrations in which case we drop the cloned
databases and recreate them. If all migrations already existed we keep
the clones the way they are?
/Markus
On Tue, Jul 05, 2016 at 09:00:25AM +0200, Aymeric Aug
I investigated the GROUP BY requirements when using an ORDER BY within
these aggregates, but there appear to be none.
Further details can be found in the discussion in Trac:
https://code.djangoproject.com/ticket/26067.
Based on this observation, I went on to create a
PR: https://github.com/djan
(I neglected to post this last week.)
Triaged
---
https://code.djangoproject.com/ticket/26779 - i18n_javascript should take
extra_context as argument (accepted)
https://code.djangoproject.com/ticket/26781 - SQLite crashes when changing
the case of db_table (accepted)
https://code.djan
Markus, I like the idea, which is definitely better than my idea of new
option to recreate it manually when we know we have to.
I can try to investigate a bit if you think that could lead to something
that makes sense.
Two ideas I have in mind after a quick look at migrate command line code:
1/
