Загрузка исходных данных с помощью Django 1.7 и миграции данных

короткая версия

вы должны не использовать loaddata команды управления непосредственно в миграции данных.

# Bad example for a data migration
from django.db import migrations
from django.core.management import call_command


def load_fixture(apps, schema_editor):
    # No, it's wrong. DON'T DO THIS!
    call_command('loaddata', 'your_data.json', app_label='yourapp')


class Migration(migrations.Migration):
    dependencies = [
        # Dependencies to other migrations
    ]

    operations = [
        migrations.RunPython(load_fixture),
    ]

текст

loaddata использует django.core.serializers.python.Deserializer который использует самые современные модели для десериализации исторических данных в миграции. Это неправильное поведение.

например, предполагается, что существует миграция данных, которая использует loaddata команда управления для того чтобы нагрузить данные от приспособления, и оно уже применяется в среде разработки.

позже вы решите добавить новый требуются поле для соответствующей модели, поэтому вы делаете это и делаете новую миграцию против обновленной модели (и, возможно, предоставляете одноразовое значение новому полю, когда ./manage.py makemigrations запрос).

вы запускаете следующую миграцию, и все хорошо.

наконец, вы закончили разработку приложения Django и развернули его на рабочем сервере. Сейчас это время для вас, чтобы запустить все миграции с нуля на производственной среде.

однако, перенос данных не. Это потому, что десериализованная модель из loaddata команда, которая представляет текущий код, не может быть сохранена с пустыми данными для нового требуются поле, которое вы добавили. Оригинальный прибор не имеет необходимых для этого данных!

но даже если вы обновите прибор с необходимыми данными для нового поля, перенос данных по-прежнему не удается. Когда миграция данных выполняется,далее миграция, которая добавляет соответствующий столбец в базу данных, пока не применяется. Вы не можете сохранить данные в столбец, который не существует!

вывод: в миграции данных loaddata команда вводит потенциальное несоответствие между моделью и базой данных. Вы должны обязательно не используйте его непосредственно в a миграция данных.

Решение

использует django.core.serializers.python._get_model функция для того чтобы получить соответствуя модель от приспособления, которое возвратит самую последнюю версию модели. Нам нужно подлатать его, чтобы он получил историческую модель.

(следующий код работает для Django 1.8.x)

# Good example for a data migration
from django.db import migrations
from django.core.serializers import base, python
from django.core.management import call_command


def load_fixture(apps, schema_editor):
    # Save the old _get_model() function
    old_get_model = python._get_model

    # Define new _get_model() function here, which utilizes the apps argument to
    # get the historical version of a model. This piece of code is directly stolen
    # from django.core.serializers.python._get_model, unchanged. However, here it
    # has a different context, specifically, the apps variable.
    def _get_model(model_identifier):
        try:
            return apps.get_model(model_identifier)
        except (LookupError, TypeError):
            raise base.DeserializationError("Invalid model identifier: '%s'" % model_identifier)

    # Replace the _get_model() function on the module, so loaddata can utilize it.
    python._get_model = _get_model

    try:
        # Call loaddata command
        call_command('loaddata', 'your_data.json', app_label='yourapp')
    finally:
        # Restore old _get_model() function
        python._get_model = old_get_model


class Migration(migrations.Migration):
    dependencies = [
        # Dependencies to other migrations
    ]

    operations = [
        migrations.RunPython(load_fixture),
    ]

вдохновленный некоторыми комментариями (а именно n_ _ o) и тем, что у меня много initial_data.* файлы, разбросанные по нескольким приложениям я решил создать приложение Django, которое облегчило бы создание этих миграций данных.

используя django-migration-fixture вы можете просто запустить следующую команду управления, и она будет искать через все ваши INSTALLED_APPS на initial_data.* файлы и превратить их в миграции данных.

./manage.py create_initial_data_fixtures
Migrations for 'eggs':
  0002_auto_20150107_0817.py:
Migrations for 'sausage':
  Ignoring 'initial_data.yaml' - migration already exists.
Migrations for 'foo':
  Ignoring 'initial_data.yaml' - not migrated.

посмотреть django-migration-fixture для инструкций по установке/использованию.

лучший способ загрузить исходные данные в перенесенных приложениях - это миграция данных (как Также рекомендуется в документах). Преимущество заключается в том, что приспособление таким образом загружается как во время испытаний, так и в процессе производства.

@n_ _ o предложил переопределить loaddata команда в миграции. В моих тестах, однако, вызов loaddata команда напрямую также отлично работает. Таким образом, весь процесс является следующим:

1. создать файл в <yourapp>/fixtures/initial_data.json

2. создайте пустую миграцию:

   python manage.py makemigrations --empty <yourapp>
   

3. изменить файл миграции /migrations/0002_auto_xxx.py

   from django.db import migrations
   from django.core.management import call_command
   
   
   def loadfixture(apps, schema_editor):
       call_command('loaddata', 'initial_data.json')
   
   
   class Migration(migrations.Migration):
   
       dependencies = [
           ('<yourapp>', '0001_initial'),
       ]
   
       operations = [
           migrations.RunPython(loadfixture),
       ]
   

чтобы дать вашей базе данных некоторые исходные данные, напишите миграция данных. При переносе данных используйте RunPython функция для загрузки данных.

Не пишите никаких команд loaddata, так как этот способ устарел.

перенос данных будет выполняться только один раз. Миграции представляют собой упорядоченную последовательность миграций. Когда 003_xxxx.py выполняется миграция, Django migrations записывает в базу данных, что это приложение переносится до этого (003), и будет выполняться только следующие миграции.

приведенные выше решения не работают для меня, к сожалению. Я обнаружил, что каждый раз, когда я меняю свои модели, я должен обновлять свои светильники. В идеале я бы вместо этого написал миграции данных для изменения созданных данных и данных, загруженных приспособлением, аналогично.

чтобы облегчить это Я написал быструю функцию которая в fixtures каталог текущего приложения и загрузить приспособление. Поместите эту функцию в миграцию в точке истории модели, которая соответствует поля в миграции.

на мой взгляд, светильники немного плохие. Если ваша база данных часто меняется, поддержание их в актуальном состоянии скоро станет кошмаром. На самом деле, это не только мое мнение, в книге "два совка Джанго" это объясняется гораздо лучше.

вместо этого я напишу файл Python для обеспечения начальной установки. Если вам нужно что-то еще, я предлагаю вам посмотреть на Фабрика мальчик.

Если вам нужно перенести некоторые данные, вы должны использовать сведения миграции.

там же "Сожгите Ваши Приспособления, Используйте Модельные Фабрики" об использовании приспособлений.