Yes, no matter what it's too late to add anything to 1.7, which is a massive shame - we'll have to just heavily document this for now, and then investigate the dump/load data stuff for the next cycle (I think it should work everywhere initial_data did, at least, as they're both fixtures).
I will try and remove that first flush before tests start, though, which would at least let you use the data inside normal TestCases on transactional DBs, though I fear removing it might be too backwards-incompatible. Andrew On Sun, Apr 20, 2014 at 12:23 AM, Anssi Kääriäinen <[email protected]>wrote: > On 04/19/2014 06:54 PM, Andrew Godwin wrote: > >> I agree we can just say that initial_data can be used as a fixture for >> tests rather than being auto-loaded - and we could perhaps even put it in >> the base testcase so it always auto-applied somehow - but that doesn't get >> over the fact that you can't rely on data migrations to set up your >> database for tests (for example, to add in required base rows or choices to >> EAV designs). >> >> I remember we reordered TransactionTestCase with respect to TestCase - >> what did we do? If we had them all at the end then we could at least have >> things work for TestCase if we remove that initial flush, but unfortunately >> I suspect option 3 might have to be the solution, and I really don't want >> to do anything with fixtures (though I guess the only performance hit is >> writing the fixture, as we would have been reading one in every time before >> anyway - initial_data). Perhaps we could cache the fixture in memory and >> then spool out to disk if it gets too big. >> >> The test case ordering is currently TestCase, SimpleTestCase and then > the rest (including TransactionTestCases). > > Using fixtures for dumping contents of the DB before first flush, and then > reloading it back after each flush seems to be doable. I am not sure how > well it will perform, or if it will be actually backwards compatible for > users in all cases. It is extremely likely there will be at least some > corner cases that can't be handled by simple dump-and-reload, so there is > likely more work than just adding the dump and reload calls in to Django. > > As for spooling out to disk - I don't think we need to do that. If the > file is small enough to stay in memory, then reading from the file should > be fast, too. If it is large, then the operating system knows better than > us when to write it out to disk. In addition, if a fixture file is too > large to stay in memory, then dump-and-restore will be too slow to be > usable in any case. > > If we want to support large amounts of data, then an approach I worked on > to speed up Django's test suite some time ago might be useful. The idea was > that only tables which were changed by a test were flushed after that test. > It worked pretty well, but it was also somewhat complex. However, if we add > an ability to have static data for tests this might need a revisit. The > approach should be extremely effective for static test data. If you have > any large amount of static test data then you don't want to reload it after > each transactional test. > > I have had a need for static data for tests in some projects, so a big +1 > for this feature. I don't see how we can make this feature reliable for 1.7 > in the time available. Can we punt this to 1.8? > > > - 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/535375E1.8060602%40thl.fi. > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAFwN1uqxhOXD%2B6D0zGVpMaF2bKTX4vzwpavDHa_Y892PXrTOMw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
