Re: Data Migrations and Testing

If you read the section on this: https://docs.djangoproject.com/en/dev/topics/testing/overview/#test-case-serialized-rollback the emulation is only performed if you set serialized_rollback = True on the TestCase (as not all tests need this and it slows tests down by 3x, so we decided to make it

Re: Data Migrations and Testing

Ticket claims this is fixed, but as I've moved my project to Django 1.7, I've seen story from OP's mail repeat. My migrations create tables, then populate them with data. Then tests that read this data from DB blurp with "DoesNotExist". > Any initial data loaded in migrations will only be

Re: Data Migrations and Testing

There's two balancing forces here - I don't want to delay the release as we always do that, but then again we always make sure we ship correct, not on time. I'll investigate this as much as I can this week, and see if I can get the dump-and-restore-to-fixture stuff working, as I think that's the

Re: Data Migrations and Testing

Hm, I’m not a core developer, but i wouldn’t prefer the documentation that explains the edge cases. As Russel Keith-Magee already said that Django is a tool that ensures quality. We should definitly make a Ticket and try to clear that thing up before the 1.7 release. I mean this is not a new

Re: Data Migrations and Testing

On Mon, Apr 21, 2014 at 11:35 PM, Andrew Godwin 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

Re: Data Migrations and Testing

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

Re: Data Migrations and Testing

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

Re: Data Migrations and Testing

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 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

Re: Data Migrations and Testing

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

Re: Data Migrations and Testing

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

Re: Data Migrations and Testing

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

Re: Data Migrations and Testing

2014-04-19 14:15 GMT+02:00 Anssi Kääriäinen : > On 04/19/2014 10:52 AM, Anssi Kääriäinen wrote: > > Getting dump-and-reload support for 1.7 seems hard, so from the above >> options this leaves just 2) - not deprecating initial_data yet. Or we >> need to find some other

Re: Data Migrations and Testing

Hi Marc. Thanks for you explanation. 2014-04-19 13:46 GMT+02:00 Marc Tamlyn : > Hi Andrey, > > There are limited use cases where initial data is a good idea. Examples > might be where you have a list of countries for relating to or some other > fixed set of data. > > The

Re: Data Migrations and Testing

On 04/19/2014 10:52 AM, Anssi Kääriäinen wrote: Getting dump-and-reload support for 1.7 seems hard, so from the above options this leaves just 2) - not deprecating initial_data yet. Or we need to find some other solution not listed above. Hmmh, there is actually a pretty straightforward upgrade

Re: Data Migrations and Testing

Hi Andrey, There are limited use cases where initial data is a good idea. Examples might be where you have a list of countries for relating to or some other fixed set of data. The idea is that now instead if having a hard to maintain fixture for that table, you populate it with a data migration

Re: Data Migrations and Testing

Hi Christian. But, as far as I know, data migrations are "some logic" for translate data from old scheme to new scheme and initial_data are files for load intial data. I do not see where they could serve for the same purpose. Is really confusing. Personally, putting initial data of my

Re: Data Migrations and Testing

hm, at first i didn't even read the release notes.. But i think we should definitly make a blocker issue in trac. Currently re-introduce initial_data is the worst thing we could do, since django 1.9 requires migrations and do deprecate that behavior: > Deprecated since version 1.7: If an

Re: Data Migrations and Testing

Hi! At this time I haven't touched the new migrations system for django. But now, reading the releases notes and this thread... I don't understand how data migrations can replace initial_data, are two things completely different and they have completely different scope. I'm slightly confusing.

Re: Data Migrations and Testing

On 04/18/2014 07:41 PM, Andrew Godwin wrote: Ah yes, flushing, I forgot we did that for lesser DBs. I can think of several solutions: - Run the entire migration set every time you flush the database. This is, obviously, not practicable. - Re-introduce initial_data fixtures; I'd rather not,

Re: Data Migrations and Testing

The first solution is definitly the worst, if you make integration tests you already have a "long running" test suite (especially with over 20-30 models). initial_data fixtures having a problem, if you change your database the initial_data will change over time, which is somehow bad to

Re: Data Migrations and Testing

Ah yes, flushing, I forgot we did that for lesser DBs. I can think of several solutions: - Run the entire migration set every time you flush the database. This is, obviously, not practicable. - Re-introduce initial_data fixtures; I'd rather not, as these require constant upkeep and interact

Re: Data Migrations and Testing

The case is really simple and i think its definitely that would block the release. First off, I have a model: from django.db import models # Create your models here. class SimpleModel(models.Model): name = models.CharField(max_length=10) Then I will make some migrations: # encoding: utf8

Re: Data Migrations and Testing

The problem might be that initial data is loaded after each database flush, but the same isn't true for migrations. If we want to have RunSQL as a complete replacement for initial data, then we need to have some way to mark data loading "migrations" to be loaded after each database flush. Of

Re: Data Migrations and Testing

Hi Christian, Can you explain your situation more, and perhaps give us some example files or console output? When you run tests they should run through all the migrations first, so any initial data should get loaded in before tests begin. Andrew On Thu, Apr 17, 2014 at 1:16 PM, Christian