3

У меня есть Django 1.7 миграции, которая выглядит примерно так:миграция данных Django терпит неудачу при запуске manage.py тест, но не при запуске manage.py мигрировать

# -*- coding: utf-8 -*- 
from __future__ import unicode_literals 

from django.db import models, migrations 

def units_to_m2m(apps, schema_editor): 
    Interval = apps.get_model("myapp", "Interval") 
    IntervalUnit = apps.get_model("myapp", "IntervalUnit") 

    for interval in Interval.objects.all(): 
     IntervalUnit(
      interval=interval, 
      unit=interval.unit, 
      base_date=interval.base_date 
     ).save() 

class Migration(migrations.Migration): 

    dependencies = [ 
     ('otherapp', '0007_auto_20150310_1400'), 
     ('myapp', '0009_auto_20150316_1608'), 
    ] 

    operations = [ 
     migrations.CreateModel(
      name='IntervalUnit', 
      # ... 
     ), 
     # ... 
     migrations.AddField(
      model_name='interval', 
      name='units', 
      field=models.ManyToManyField(to='otherapp.Unit', through='myapp.IntervalUnit'), 
      preserve_default=True, 
     ), 
     migrations.RunPython(units_to_m2m), 
     migrations.RemoveField(
      model_name='interval', 
      name='unit', 
     ), 
     migrations.RemoveField(
      model_name='interval', 
      name='base_date', 
     ), 
    ] 

Когда я бегу manage.py migrate, он мигрирует просто отлично , Когда я бегу manage.py test, однако, он пытается создать тестовую базу данных, а затем терпит неудачу в середине этой миграции со следующей ошибкой:

Traceback (most recent call last): 
... 
    File "/home/adam/myproject/myapp/migrations/0010_auto_20150317_1516.py", line 10, in units_to_m2m 
    for interval in Interval.objects.all(): 
... 
django.db.utils.OperationalError: (1054, "Unknown column 'myapp_interval.base_date' in 'field list'") 

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

Edit: Я пытался расколоть миграцию на три отдельных миграций, один, содержащий все вещи перед RunPython один, одна из которых RunPython сам по себе, и один, содержащий все вещи, которые впоследствии; он все еще делает то же самое.

+0

Миграции должны быть в порядке, пока не достигнет «migrations.RunPython (units_to_m2m)». Кажется, что модель «планирования» еще не готова для этой операции в «myapp_interval.base_date». Я бы постарался поставить эту модель как зависимость и посмотреть, каков результат. – brunofitas

+0

«scheduling» и «myapp» - это одно и то же, я просто не могу анонимизировать код правильно: S –

ответ

0

Оказывается, миграции выполнялись успешно, в том порядке, в котором они должны были быть, но у меня есть две базы данных, и она выполняла мои миграции на обоих без консультации с маршрутизатором базы данных. Билет Django для отслеживания этой проблемы - #23273, который по-прежнему открыт.

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

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

1

Это немного странно, и мы не знаем, почему это работает, но мы изменили нашу allow_migrate подпись на нашем маршрутизаторе следующее:

def allow_migrate(self, db, app_label, **hints): 
    """ 
    Make sure the mydb db does not allow migrations 
    """ 
    if db == 'mydb': 
     return False 

    return True 

И эта ошибка таинственно ушел. Обратите внимание, что эта подпись не соответствует тому, что содержится в документации 1.8 (мы используем 1.8.2) allow_migrate(db, app_label, model_name=None, **hints), как показано здесь: https://docs.djangoproject.com/en/1.8/topics/db/multi-db/#allow_migrate

Но, надеюсь, это вам поможет?

+0

Я не понимаю, почему это тоже работает, но для меня эта проблема была решена. Благодарю. – shacker

Смежные вопросы