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 <anssi.kaariai...@thl.fi>:

> 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.
>



-- 
Andrey Antukh - Андрей Антух - <andrei.anto...@kaleidos.net> / <n...@niwi.be
>
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 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/CAKn%3DmOMtrLNBZ%2BNfjz6GCpg-8sKQQ7iEKBhP40fOsCR_KtWfyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to