Hi! At this time I haven't touched the new migrations system for django. But now, reading the releases notes and this thread... I don't understand how data migrations can replace initial_data, are two things completely different and they have completely different scope. I'm slightly confusing.
In any case, great work. Thanks Andrey 2014-04-19 9:52 GMT+02:00 Anssi Kääriäinen <[email protected]>: > 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 [email protected]. > To post to this group, send email to [email protected]. > 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. > -- Andrey Antukh - Андрей Антух - <[email protected]> / <[email protected] > http://www.niwi.be <http://www.niwi.be/page/about/> https://github.com/niwibe -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAKn%3DmOMtrLNBZ%2BNfjz6GCpg-8sKQQ7iEKBhP40fOsCR_KtWfyQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
