Нет, там можно без проблем на каждый отдельный app вызывать свою миграцию.

Например manage.py migrate my_special_app_name — сделает миграцию только для этой аппликухи

Понял почему таблицы удаляются с алембиком. Это когда я делаю миграции чере —autogenerate, то он на законных основаниях пологает, что раз таблиц не видно через target_metadata, значит надо создать им op.drop_table()

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

И какой-то чудо настройки для именно при —autogenerate возможно и не сделать, не задав явно список таблиц в excude настройке.

+

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

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

Если этот несвязанные модули, зачем им общая база?

В общем, я не знаю хорошего решения с алембиком. Но по-моему, лучше несвязанные вещи реально изолировать, чем огребать какие-то особенности в духе "в двух проектах создал одну таблицу" или ещё что

У меня есть список проектов, каждый имеет свою БД, свой отдельный репозиторий:
- project1
- project2
- project3
…

Каждый из этих проектов пользуется отдельным модулем, в котором вынесена общая логина этих проектов:
- shared_app
, в этом модуле есть таблицы, шаблоны и прочее. Этот модуль реализован в виде пакета, живет в приватном pypi сервере.

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

Ээ

То есть модули на самом деле не независимые? Тогда зачем их независимо хранить и независимо генерировать миграции?

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

Если у тебя была описана модель1 а потом появилась модель2, алембик же не узнает, что существуют другие модули с модель100 и не будет пытаться удалить.

А ты когда-то работал с django? Там есть концепция, что в одном проекте может быть несколько аппликух. И эти аппликухи не должны быть в одном репозитории, их можно реюзать.

Вот у меня точно такая же концепция моих проектов. Вобщем в терминалогии фласка это наверное будет так: у меня есть один блупринт, но у которого есть не только вьюхи, но и таблицы в БД. И этот блупринт я использую в куче разных проектов.

А сам блупринт расположен в отдельном репозитории

Я не работал с Джанго. Каждый раз когда его трогаю, меня выворачивает от количества костылей

Ну так генерируй миграции для каждого модуля, в чем проблема?

Да, костыли там есть, но есть и крутые штуки. Вот как раз возможность сделать свой my-cool-app (с БД, с шаблонами и кучей всего), а потом в новом проекте добавить его как pip install my-cool-app — это очень клевая штука для создания реюзабельных модулей.

Если таблиц не видно, но их и не было, он не будет генерировать дроп

Вот и генерю. Но оказалось, что если делать через --autogenerate, то он удаляет таблицы из предыдущей миграции. Но это решается чрез include_object, который я уже нагуглил

Из предыдущей удаляет, да

Так ты генерируй миграции для каждого модуля отдельно

В пределах его репозитория