Hello, > On 5 juli 2016, at 00:22, Romain Garrigues <romain.garrigues...@gmail.com> > wrote: > After some investigation, I have seen that, in case of keepdb context, in > django/db/backends/*/creation.py, if the cloned databases already exist, we > don't touch them, which leads to this new field not created in cloned ones. > > I have proposed in the PR to rebuild the cloned databases, even with keepdb > option, to be sure that we always have the cloned databases with the latest > migration state. > > The problem with this method is that it will increase test database > initialization time, as we will now systematically copy all cloned databases, > even with --keepdb option (except the default one).
We’ve been doing similar things in pytest-django (with the --reuse-db option and pytest-xdist) and faces similar problems. Currently you have to force-recreate the databases and then all processes will run migrations and it is very slow. I’ve been playing around with a solution to this: In my own project I create a template database and call it `test_myproject_<sha1 of all migration files>`. Whenever a migration file changes (an existing file or a new migration file) - a new database is created and all clones are recreated. Currently this lives as a hack in my own code base, but I would like to explore this further and it could be a way forward. Here is my scripts that calculates the hash and creates the databases: https://gist.github.com/pelme/4b3dac475cd6b1dec4fd67d25d2e7cdc https://gist.github.com/pelme/4a3ad3a62b6244068ff63736342f9509 This method could be refined: It is not necessary to create a database with a new name every time migrations change. I.e. we could create a private table with a single row that contains the hash. This approach hashes only the migration files directly involved in migrations, if you are using a 3rd-party library that’s imported, that will not trigger a new migration run. As an end user of this the experience is quite nice: You only experience the migration/cloning slowness whenever migrations actually changed, otherwise everything is fast. You don’t have to remember any special command line options. Cheers, Andreas -- 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/5A553E81-F6FF-4A85-ADB3-01D66AE072B9%40pelme.se. For more options, visit https://groups.google.com/d/optout.
