Are you thinking the next cycle would be 1.7.1 or 1.8?
On Mon, Apr 21, 2014 at 11:35 AM, Andrew Godwin <[email protected]> wrote: > 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<https://groups.google.com/d/msgid/django-developers/CAFwN1uqxhOXD%2B6D0zGVpMaF2bKTX4vzwpavDHa_Y892PXrTOMw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > 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/CAGdCwBs7pYDv7FxPZGb8MvuW_ou5HdzQcGd4Z37ghwTAmsNNNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
