Советы по написанию миграции данных в приложении Django

Введение

В приложении Django при изменении схемы Django автоматически создает файл миграции для изменений схемы. Мы можем написать дополнительные миграции для изменения данных.

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

Используйте команды управления

Приложения могут регистрировать пользовательские действия с manage.py, создавая файл в каталоге management/commands приложения. Это позволяет легко (повторно) запускать и тестировать миграции данных.

Вот команда управления, которая переносит столбец status модели Task.

from django.core.management.base import BaseCommand
from library.tasks import Task

class Command(BaseCommand):

    def handle(self, *args, **options):
        status_map = {
            'valid': 'ACTIVE',
            'invalid': 'ERROR',
            'unknown': 'UKNOWN',
        }
        tasks = Task.objects.all()
        for tasks in tasks:
            task.status = status_map[task.status]
            task.save()

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

Связывание вместе миграции данных и миграции схемы

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

def run_migrate_task_status(apps, schema_editor):
    from library.core.management.commands import migrate_task_status
    cmd = migrate_task_status.Command()
    cmd.handle()


class Migration(migrations.Migration):

    dependencies = [
    ]

    operations = [
        migrations.RunPython(run_migrate_task_status, RunSQL.noop),
    ]

Будьте остородны при запросах к БД

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

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

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

# вместо
User.objects.all ()

# использовать
User.objects.only ('id', 'is_active')

В качестве альтернативы мы можем использовать необработанные SQL-запросы для миграции данных.

Заключение

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

Вернуться на верх