Yes, the test suite is basically the biggest obstacle to full usage of migrations - I've tried to make it see sense, but given my limited time at the moment and the fact that it's a tortuous mess of hacks in places it means that I can't see that happening before the RC.
I'd like to have started the Creation deprecation cycle this release, but it's probably fine if we let that slip a release (it's going to be harder to remove than many other features). Migrations will hopefully drive the adoption of SchemaEditor by developers and third-party backends anyway. Andrew On Mon, Apr 21, 2014 at 9:21 AM, Tim Graham <[email protected]> wrote: > I have been thinking that maybe we should delay #22340 (Legacy Table > Creation Methods Not Properly Deprecated) until 1.8 so that migrations > won't be required until Django 2.0. I'm not sure how feasible it is to > remove Django's test suite usage of it in the next week and a half, if we > are still shooting for RC1 on May 1 or shortly thereafter. > > > On Monday, April 21, 2014 12:06:10 PM UTC-4, Michael Manfre wrote: > >> 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/ms >>>> gid/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/b41c51ab-d029-4afc-90e2-d1e2c0927e67%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/b41c51ab-d029-4afc-90e2-d1e2c0927e67%40googlegroups.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/CAFwN1urOPE9fe8S%2BNEmYcz0OfO08XHRR8%2B7HJSRTqXp1NF-7Fw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
