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.
