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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* stage: Unreviewed => Accepted
* severity: Normal => Release blocker
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:1>
Comment (by merb):
https://docs.djangoproject.com/en/dev/releases/1.7/#schema-migrations
It's wrong in the docs. If you use both it won't work.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:2>
Comment (by linovia):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:3>
Comment (by timo):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:4>
Comment (by merb):
ouch i've just seen some easier way maybe.
check that patch...
https://code.djangoproject.com/attachment/ticket/23077/new-23077.diff
If totally overseen the load_initial_data flag
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:5>
Comment (by merb):
if this is the desired behavior i would write a test, that tests the test
runner.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:6>
* cc: timo (added)
* has_patch: 0 => 1
* needs_tests: 0 => 1
Comment:
Looks good to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:7>
Comment (by timo):
It may be easier/simpler to keep the test localized to the migrate command
instead of testing the behavior indirectly through the test runner.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:8>
* status: new => assigned
* owner: nobody => andrewgodwin
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:9>
Comment (by andrewgodwin):
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:10>
* status: assigned => closed
* resolution: => invalid
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:11>
Comment (by Andrew Godwin <andrew@…>):
In [changeset:"2bacc9f3b70e45b172675452b7dd32900fbb8a8b"]:
{{{
#!CommitTicketReference repository=""
revision="2bacc9f3b70e45b172675452b7dd32900fbb8a8b"
[1.7.x] Mark initial_data as deprecated separately from syncdb. Refs
#23077.
Conflicts:
docs/internals/deprecation.txt
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/23077#comment:12>