Как в Django организовать миграцию для двух связанных моделей с автоматической подстановкой дефолтных значений поля?

Question

[Megadeth77]

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

Есть модель скажем Model, в ней есть foregin keys на другие модели.

class ModelA: ...
class ModelX: ...

class Model:
  a = models.ForeignKey(ModelA, default=A)
  x = models.ForeignKey(ModelX, default=X)

И вот в один прекрасный момент мы создаем еще одну модель (ModelY) на которую должна ссылаться Model. И при создании Model у объекта должна быть ссылка на какой то дефолтный объект ModelY, которого еще очевидно нет!

class ModelY: ...
class Model:
  y = models.ForeignKey(ModelY, default=??????)

Т.е. последовательность при миграции должна быть такой:
-Создать таблицу ModelY
-Создать в этой таблице дефолтный объект, куда то записать его id
-Создать новое поле в таблице Model, причем дефолтное значение взять из предыдущего пункта

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

Есть какие то best prectice для такого случая ? Или хотя бы по каким ключевым словам гуглить?

Answer 1

[marazmiki]

Сценарий для джанги я бы предложил такой:

1. Создать модель ModelY, сгенерировать и применить соответствующую миграцию.
   
2. Добавить в Model необязательный (т.е. null=True) внешний на ModelY. Сгенерировать миграцию и применить её.
   
3. Создать дата-миграцию, в которой создадим "дефолтный" объект ModelY. Накатить её.
   
4. Изменить внешний ключ (см. п.2) таким образом, чтобы он подставлял дефолтное значение. Пока не убирать null=True. Накатить. Теперь все вновь созданные модели будут создаваться правильно
   
5. Создать дата-миграцию, которая заменила бы все нулевые внешние ключи на дефолтный объект. Накатить.
   
6. Теперь можно сделать внешний ключ из п.2. обязательным, т.е. убрать null=True.

Что же касается best practices, то из опыта я бы посоветовал следующее:

• Не надо пытаться минимизировать число миграций или засунуть всё в одну. Напротив, лучше идти по пути упрощения миграций, а не уменьшия их количества.
  
• Миграции лучше делать максимально независимыми друг от друга.
  
• Не нужно заморачиваться с two-way; если какое-то решение оказалось неудачным, лучше сделать ещё одну миграцию, которая делает противоложную операцию относительно предыдущей, чем откатываться.
  
• Если добавляете новое поле, обязательно делайте его сперва null, а лишь потом заполняйте.

Comments

[Megadeth77]

Спасибо. Но это как минимум не будет работать в автоматическом режиме. Т.е. например мне надо развернуть тестовую базу, т.е. создать ее с нуля, как я буду менять в п4 внешний ключ? В коде?

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

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

upd, хотя какая функция в модели... Дефолтное значение же в схеме данных должно поселиться...

[marazmiki]

Это всё прекрасно работает в автоматическом режиме.

Я показал сценарий создания и обновления схемы на живой базе. На тестовой же всё гораздо проще. Просто запускаете migrate, и миграции выполняются последовательно. Сами появляются налловые поля, сами создаются дефолтные объекты, сами налловые поля заменяются на дефолты и так далее.

[Megadeth77]

id созданного объекта то как протаскивать в миграцию? Очевидно в разных базах id разный, в код его прописывать нельзя, надо откуда то тянуть динамически.

[marazmiki]

Открою маленький секрет: в Вашем случае как только вы создалите модель ModelY, создастся абсолютно пустая таблица, которую ещё никто не использовал. В следующем шаге (миграции) Вы можете сделать так:

default_model_y = ModelY.objects.create(name="Default one")

и достоверно считать, что у дефолтной модели ID=1.

Не нравится неявность? Не вопрос, укажите при создании айдишник явно:

default_model_y = ModelY.objects.create(id=1, name="Default one")

.
Я бы, правда, не советовал ставить что-то отличное от единицы.

Но и это ещё не всё. Никто ведь не запрещает резолвить модели не по айдишнику. К вашим услугам вся мощь DSL, который понимают .filter() или .exclude()

[Megadeth77]

Кривовато это. А если ModelY например не создается, а в Model просто появляется новое поле со ссылкой на уже имеющуюся модель? Т.е. объект будет создаваться в существующей таблице, там уже нельзя закладываться на 1цу.

резолвить понятно можно, но задача прописать именно дефолтное значение, как его там резолвить?

[marazmiki]

Да нет ничего кривоватого, всё замечательно :)

А если ModelY например не создается, а в Model просто появляется новое поле со ссылкой на уже имеющуюся модель?

Никакой проблемы. Укажите значение по умолчанию в виде callable:

def get_existing_default_model():
    return ExistingModel.objects.get(name="A default one")

class Model(models.Model):
    # ...
    existing_model = models.ForeignKey(ExistingModel, on_delete=models.CASCADE, default=get_existing_default_model)

[Megadeth77]

Да, пожалуй так наверное ок. Не primary key, а например действительно поле name какоеньть сделать и по нему резолвить в callable ок. Что то я протупил, мне казалось default value должно встать на уровне sql в базе.

Спасибо.