Update Base model

[V-pix]

No description provided.

[AntonZelinsky]

Так, вроде всё хорошо, но нужно ещё мигрировать данные. Посмотри ПР Ани, где она мигрировала данные и сделай так же.
Что мигрировать? у таск поля created_date и updated_date; у статистики added_date; у причины отмены added_date и updated_date; у внешнего пользователя created_date и updated_date.
То есть, тебе нужно сначала выполнить те миграции которые уже созданы, потом, в этом же файле идёт миграция данных, где ды данные из этих колонок перегоняешь в соответствующие, а потом, удаляешь старые колонки из базы. И это тоже всё в одной миграции сделать нужно.
Хорошо бы ещё у натификейшенов перегнать из sent_date, в дату создания, но старое поле удалять не обязательно.

[AntonZelinsky]

Предлагаю избавиться от этого поля. Что-то я не нашёл сценариев его использования. Если брать вариант замены архивации, то лучше не будем этого делать, а то выигрыша нет, а в дебри залезем.

[AntonZelinsky]

Это что-то из старого кода осталось.

[ani-zia]

Привет!
У меня вопрос по таблицам:

Таблица Task уже имеет свои аналоги поля created_at, updated_at - поэтому в миграции у них меняется только название, а данные сохраняются.

Но свои аналоги полей created_at, updated_at есть и у других таблиц в БД

• Statistics имеет одно поле added_date - это не аналог created_at?
• ReasonCanceling имеет поля added_date, updated_date
• ExternalSiteUser имеет поля created_date, updated_date

Может для этих таблиц тоже стоит только перепаивать колонки по-новому, а не создавать новые?

@AntonZelinsky скажи, пожалуйста, эти поля (created_date, added_date) схожи у таблиц и подойдут ли им на замену поля базовой модели?

[AntonZelinsky]

Точно, Аня, спасибо. Ты очень умная и наблюдательная.
Я какое-то костыльное решение предлагаю.(
Там где есть аналогичные колонки которые собирались удалять, не нужно их удалять, а просто переименовать.

[V-pix]

Добрый день!

Вчера созвонились с Аней и нашли решение только без переопределения Base (закомменченная часть в models.py). Если переопределять базовую модель, то не проходит предыдущая миграция, которую Аня писала. Ссылка на описание ошибки в Пачке https://app.pachca.com/chats/3910846?thread_id=167839 .

И еще у нас есть вопросы:

• В задаче Notion написано, что надо сделать две миграции, и среди старых миграций есть две миграции - одна добавляет колонки, вторая меняет тип колонок. Вопрос – надо две миграции на добавление и изменение названия колонок, или можно все в одной миграции сделать?

• Нормально ли решение, что создаются поля с пустыми значениеми (если такого поля с данными не было в базе), или надо прокидывать TIMESTAMP с временем сервера?

• И итоговый вопрос, делать ли переопределение Base, в таком случае нужно будет менять миграцию Ани, подробнее об это она расскажет

[ani-zia]

•И итоговый вопрос, делать ли переопределение Base, в таком случае нужно будет менять миграцию Ани, подробнее об это она расскажет

Да, подтверждаю что моя миграция падает на этом запросе в базу:
parent_categories = set(db_session.execute(select(Category).join(Users_Categories).where(Category.parent_id.is_(None))).scalars())

потому что пытается забрать из базы все поля модели Category, в том числе пока не существующие поля created_at, updated_at которые только в следующей миграции подъедут :(
Вот запрос из трейса ошибки:
[SQL: SELECT categories.created_at, categories.updated_at, categories.id, categories.name, categories.archive, categories.parent_id FROM categories JOIN users_categories ON categories.id = users_categories.category_id WHERE categories.parent_id IS NULL]

PS. мы не смотрели все более старые миграции, не знаю, проходят ли они)
@AntonZelinsky
Как поступать на проектах в таких случаях, когда меняется родительская модель и надо все миграции переписывать получается?