Opened 2 years ago

Closed 2 years ago

Last modified 12 months ago

#22831 closed New feature (wontfix)

Migrations should provide a way to dumpdata to an initial data migration

Reported by: gcbirzan Owned by: nobody
Component: Migrations Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

People with existing south migrations that contain any kind of data migrations will need to dump their initial data in a fixture and re-create it with 1.7 migrations. This is impossible in the current state unless a) there's an undocumented way to do it, b) one uses mock (or monkey patches by hand) to change django.core.serializers.python._get_model to the one from the migration.

The reason that b is needed is because if you modify the model afterwards, loaddata will explode since the model is different.

Additionally, since migrations are now almost 10 times slower than with south, nobody will want to create proper data migrations, so this is really the best way to 'upgrade' from south.

Change History (6)

comment:1 Changed 2 years ago by Marc Tamlyn

Summary: Migrations should provide a way to 'upgrade' from south via loaddataMigrations should provide a way to dumpdata to an initial data migration
Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature
Version: 1.7-beta-2master

I agree there is no current "dumpdata" to get an initial data migration. This would likely be helpful, and is a new feature. It's actually orthogonal to updating from South - any situation where you would previously have done a dumpdata > initial_data.json you now wish to do a dumpdata > initial_migration. I think this feature is likely useful, though the implementation is probably hard and I do not feel its absence is a release blocking issue.

I'm concerned about your comments about migrations speed and upgrading from South. However this ticket is now about adding a new feature to the migrations framework - if you have concerns about migration's performance please raise a separate ticket or open a discussion on django-dev.

comment:2 Changed 2 years ago by gc@…

The implementation should be trivial. Ours, granted, using mock, looks like this:

def loaddata(app_registry, fixture_name):
    from mock import patch
    _get_model = app_registry.get_model

    with patch('django.core.serializers.python._get_model', _get_model):
        from django.core.management import call_command
        call_command("loaddata", fixture_name)

Obviously, that's a hack, but in a more generic way, this get_model can be passed all the way down to the serializer. Yeah, okay, maybe not exactly trivial, but close enough.

As for the speed... I could open a discussion, sure, but tomorrow.

comment:3 Changed 2 years ago by mardini

#22608 covers migrations slow performance.

comment:4 Changed 2 years ago by Andrew Godwin

Resolution: wontfix
Status: newclosed

I don't see what's being asked for here. Django 1.7 and migrations don't support initial data fixtures, and in addition you're encouraged to do data migrations using the ORM and RunPython rather than calling loaddata (I don't want to have to make loaddata take an Apps object to get the right set of models).

If you have existing South data migrations, you can literally do a find-and-replace to make the same code work inside RunPython - just exchange ormapp.Model? for apps.get_model('app', 'model').

comment:5 Changed 13 months ago by Thomas Güttler

Since this is closed as "wontfix" (which is ok for me), here is a guide how to do this on your own:

http://stackoverflow.com/a/25981899/633961

comment:6 Changed 12 months ago by Markus Holtermann

As luckily mentioned on Stackoverflow, all Django implementations that rely on django.core.serializers will not work reliably in migrations as that code will use the models from models.py and not from your migration state!

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