On 04/18/2014 07:41 PM, Andrew Godwin wrote:
Ah yes, flushing, I forgot we did that for lesser DBs.
I can think of several solutions:
- Run the entire migration set every time you flush the database.
This is, obviously, not practicable.
- Re-introduce initial_data fixtures; I'd rather not, as these
require constant upkeep and interact badly with migrations.
- Dump the content of all apps at the start of tests into a file and
restore from that after flushes. This is a bit hacky and might use a
lot of disk space, but would get the intended effect.
- Say that you can't use datamigrations if you have a database
without transactions (not ideal)
Nothing here is really a great solution, alas. The fourth one is the
easiest solution - tell people to use factories in tests or fixtures
if they want that stuff - but slightly undermines the idea of loading
initial data in a migration (which is the better way of doing it).
Perhaps we should look into deprecating flushing? It's not a behaviour
that can be easily replicated any more, as it relied on the old system
of one-shot schema and load a single file, but it's also kind of
crucial to non-transactional tests...
Unfortunately deprecating flushing isn't possible. For each test in
TransactionTestCase Django flushes the database. So, this problem hits
everybody using initial_data and TransactionTestCase independent of
transaction support of the database used.
As for why things break for normal TestCase, too - after creating the
database and running all the migrations Django flushes the database - so
all migration data is flushed, too.
Of the above choices that leaves only the first three, and of those the
first is already ruled out.
Option 3) might actually work pretty well. Dump all data for managed
tables just after migrations have ran, then load it back after each
flush. If the data amounts are too large to make this practical, then
they surely were impractical for initial_data or fixtures, too. In
addition we could use faster forms of data loading (COPY for PostgreSQL,
similar optimizations exists for other databases, too).
Even if one isn't using any initial data in their project, Django does
it with contenttypes and permissions. We already optimized this for
Django's test suite, and this resulted in more than halving the runtime
of the suite (granted, Django's test suite has more models than normal
projects).
Getting dump-and-reload support for 1.7 seems hard, so from the above
options this leaves just 2) - not deprecating initial_data yet. Or we
need to find some other solution not listed above.
- Anssi
--
You received this message because you are subscribed to the Google Groups "Django
developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/53522B3C.3050901%40thl.fi.
For more options, visit https://groups.google.com/d/optout.