Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#23077 closed Bug (invalid)

Django 1.7 rc1 flush command loads initial data regardless of the migrations

Reported by: linovia Owned by: Andrew Godwin
Component: Migrations Version: 1.7-rc-1
Severity: Release blocker Keywords:
Cc: xordoquy@…, Tim Graham Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no


This is following ticket #23031

We have an issue with test runner that crashes on application that has both initial_data and migrations.
The reason is the database is flushed before the migration however, flush command will try to load initial_data anyway. This will crash the test runner.
Following the documentation, initial_data is deprecated, not yet forbidden at all.

Attachments (2)

23077.diff (1.5 KB ) - added by merb 10 years ago.
new-23077.diff (470 bytes ) - added by merb 10 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 by Tim Graham, 10 years ago

Severity: NormalRelease blocker
Triage Stage: UnreviewedAccepted

comment:2 by merb, 10 years ago

That is somewhat funny.

I don't know if this is a good solution. But I wrote a patch for it. And attach it here.

Somehow migrated apps who has fixture were loaded, too.

I don't have any output yet since I didn't know if this is wished. Maybe a Note at the start of loaddata would be enough since its in the patchnotes anyway.

Oh and running against master works fine. (PY27, PY34)

Last edited 10 years ago by merb (previous) (diff)

by merb, 10 years ago

Attachment: 23077.diff added

comment:3 by linovia, 10 years ago

Doesn't the patch prevents any load data for migrated application ?
I mean, it looks like Django wouldn't be able to use loaddata for any migrated application which I is not something we want, do we ?
All I can see in the release notes is that initial_data shouldn't be possible for migrated apps.

comment:4 by Tim Graham, 10 years ago

I agree with @linovia. I looked at it briefly and I think we could probably pass the test_database flag from migrate to loaddata (via flush) and check that before skipping initial data for apps with migrations.

comment:5 by merb, 10 years ago

ouch i've just seen some easier way maybe.

check that patch...

If totally overseen the load_initial_data flag

Edit: now it won't load initial_data on migrate (which is the behavior told in the docs)

Last edited 10 years ago by merb (previous) (diff)

by merb, 10 years ago

Attachment: new-23077.diff added

comment:6 by merb, 10 years ago

if this is the desired behavior i would write a test, that tests the test runner.

comment:7 by Tim Graham, 10 years ago

Cc: Tim Graham added
Has patch: set
Needs tests: set

Looks good to me.

comment:8 by Tim Graham, 10 years ago

It may be easier/simpler to keep the test localized to the migrate command instead of testing the behavior indirectly through the test runner.

comment:9 by Andrew Godwin, 10 years ago

Owner: changed from nobody to Andrew Godwin
Status: newassigned

That patch will disable initial data loading for _all_ apps - it should be disabled for just the ones with migrations. I'll modify flush to only load apps mentioned in loader.unmigrated_apps.

comment:10 by Andrew Godwin, 10 years ago

After actually looking into this, there is no way to prevent people mentioning models that are migrated in fixtures in unmigrated apps (Django doesn't segregate models during fixture loading), so I'm going to say this is still a documentation issue and that you should just delete the initial_data fixtures from your migrated apps.

Additionally, I'm going to start initial_data on the deprecation path, so if you run with pending deprecation warnings turned on you'll see errors (and you'll definitely see them in 1.8).

comment:11 by Andrew Godwin, 10 years ago

Resolution: invalid
Status: assignedclosed

comment:12 by Andrew Godwin <andrew@…>, 10 years ago

In 2bacc9f3b70e45b172675452b7dd32900fbb8a8b:

[1.7.x] Mark initial_data as deprecated separately from syncdb. Refs #23077.



Note: See TracTickets for help on using tickets.
Back to Top