#Вопрос У меня в проекте полтора десятка приложений. Одно меня что-то

достало. И я решил почистить все миграции в нем и сделать эти миграции заново. Открыл psql и попытался дропнуть все таблицы этого приложения:

drop table tmplts_arbitraryhtml, tmplts_branchtmplt, tmplts_semanticslevel2tmplt, tmplts_specialbranchtmplt, tmplts_specialsemanticslevel2tmplt;

Получил: ERROR: cannot drop desired object(s) because other objects depend on them
DETAIL: constraint dashboard_branchsema_semantics_tmplt_id_d4aa19f9_fk_tmplts_sp on table dashboard_branchsemanticstemplate depends on table tmplts_specialsemanticslevel2tmplt

HINT: Use DROP ... CASCADE to drop the dependent objects too.

В общем, дропнул я их каскадно, как тут сказано.

Теперь, когда делаю python manage.py makemigrations, получаю:

The field dashboard.BranchSemanticsTemplate.semantics_tmplt was declared with a lazy reference to 'tmplts.specialsemanticslevel2tmplt', but app 'tmplts' isn't installed.


Скажите, пожалуйста, что как надо было правильно дропнуть миграции и создать их заново? Я просто достану все из гита и дропну заново. Мне бы просто на будущее понимать что-то про миграции. А то я с ними вечно куда-то влипаю.

Снеси базу, снеси миграции, в парке миграций создай инит, сделай новые

Это хорошо для игрушечного проекта. А для боевого проекта снести миграции - что-то как-то не хочется. У меня проект учебный, правда. Но я учусь для боевых условий, а не для поиграться. В боевых условиях разве можно снести все миграции?

Так ты спросил как миграции снести

Нет. Я не так спросил. Я спросил: как правильно их снести. А просто снести - ну, тут много ума не надо.

Твое понимание "правильного сноса" не явно

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

Что ты подразумеваешь под "сносом миграций"?

Удалить миграции полностью для данного приложения. И потом заново их создать скриптом.

Ну удалить ты можешь просто их из папки, а вот создать их просто так не получится

Просто удалить миграции в боевом проекте? И это правильно? Так получается, что миграции вообще не нужны что-ли? Ну, а иначе как их так можно просто удалить?

В боевом проекте никогда не удаляют миграции

Ну, а зачем тогда это предлагать?

Ты спросил

да, я спросил. но не надо вот вредных-то советов давать.

Сам ты вредный

Нужно было откатывать миграции средствами джанго, а не через PG. Когда миграции откатили, ее файл в папке можно удалить. Сейчас беда в том, что боевую базу ты уже попортил, надо смотреть что именно.

Вот так? ./manage.py migrate my_app 0010_previous_migration

Поэтому надо с копиями базы играться

можно просто ./manage.py migrate my_app 0010

Что-то я думаю,не поможет это. Потому что другие приложения зависят от этого. До какой же миграции откатывать. До инит что-ли? Ну, а инит-то останется. Как же чиститься?

А зачем вообще откатываться?

Да я постоянно что-то делаю не так. Потом чищусь. Может, я неправ.

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

Во, в доке есть такое: python manage.py migrate books zero Может, мне его как раз использовать.

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

А как надо делать? Вот я развернул проект в среде разработки. Долго дергал модель. И счел ее удовлетворительной. Но я накопил десяток миграций. Правильно было засечь последнюю миграцию, откатить до нее. Сделать makemigrations. И потом только одну дополнительную миграцию уже в прод передавать. Так?

Иногда делаю также, иногда делаю squashmigrations

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

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

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

ну кто тебе запрещает? пиши на spring 10 тысяч строк кода, вместо полтинника на джанге