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 <timogra...@gmail.com> 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 <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.ka...@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-develop...@googlegroups.com. >>>> To post to this group, send email to django-d...@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/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 django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@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/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 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/CAFwN1urOPE9fe8S%2BNEmYcz0OfO08XHRR8%2B7HJSRTqXp1NF-7Fw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
