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 <and...@aeracode.org> 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 < > anssi.kaariai...@thl.fi> 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 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/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 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/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 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/CAGdCwBs7pYDv7FxPZGb8MvuW_ou5HdzQcGd4Z37ghwTAmsNNNQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
