T
А. Я понял, в самое базе же ещё таблица с инфой о применённых миграциях
Size: a a a
2020 March 23
T
Сорри
T
Вот и генерю. Но оказалось, что если делать через --autogenerate, то он удаляет таблицы из предыдущей миграции. Но это решается чрез include_object, который я уже нагуглил
T
Возможно вот это подскажет ещё
MB
Не, я уже нашел, это делается примерно так:
, но в моем случае надо будет указать не только таблицы, но еще и секвенсы и индексы. Именно в моем случае, когда у меня есть кучу проектов и все они используют только один общий модуль, это выполнимо. Так как я могу реально захардкодить все сущности БД этого общего модуля.
Но вот как на алембике писать когда у тебя в одном проекте будут использоваться много модулей со своими таблицами — вот это уже даже ума не приложу как возможно сделать.
И это второй пример, что я нашел, чем джанга лучше мира фласка.
В джанге в таблица миграций там есть несколько колонок, в том числе и названия аппликухи. Т.е. там можно вызвать миграцию не для проекта целиком, а только для его части.
def include_object(object, name, type_, reflected, compare_to):
if type_ == 'table' and name in ('table', 'names', 'to', 'skip'):
return False
return True
# in env.py
context.configure(
# ...
include_object=include_object
)
, но в моем случае надо будет указать не только таблицы, но еще и секвенсы и индексы. Именно в моем случае, когда у меня есть кучу проектов и все они используют только один общий модуль, это выполнимо. Так как я могу реально захардкодить все сущности БД этого общего модуля.
Но вот как на алембике писать когда у тебя в одном проекте будут использоваться много модулей со своими таблицами — вот это уже даже ума не приложу как возможно сделать.
И это второй пример, что я нашел, чем джанга лучше мира фласка.
В джанге в таблица миграций там есть несколько колонок, в том числе и названия аппликухи. Т.е. там можно вызвать миграцию не для проекта целиком, а только для его части.
T
Я понятия не имею как это вообще может работать. В реальности ты все равно проект целиком только можешь деплоить
T
Или делаешь микросервисы нормальные
T
Без общей части
V
Джа то, джа это, не проще остаться на джа тогда, зачем тебе фласк?
V
Не пытайся пожалуйста перенести концепции джа в фласк, джа изначально строился с поддержкой модулей.
V
И сейчас в итоге имеет хорошую помойку зависимостей на этом фоне
T
Не пытайся пожалуйста перенести концепции джа в фласк, джа изначально строился с поддержкой модулей.
Нет
T
Не, я уже нашел, это делается примерно так:
, но в моем случае надо будет указать не только таблицы, но еще и секвенсы и индексы. Именно в моем случае, когда у меня есть кучу проектов и все они используют только один общий модуль, это выполнимо. Так как я могу реально захардкодить все сущности БД этого общего модуля.
Но вот как на алембике писать когда у тебя в одном проекте будут использоваться много модулей со своими таблицами — вот это уже даже ума не приложу как возможно сделать.
И это второй пример, что я нашел, чем джанга лучше мира фласка.
В джанге в таблица миграций там есть несколько колонок, в том числе и названия аппликухи. Т.е. там можно вызвать миграцию не для проекта целиком, а только для его части.
def include_object(object, name, type_, reflected, compare_to):
if type_ == 'table' and name in ('table', 'names', 'to', 'skip'):
return False
return True
# in env.py
context.configure(
# ...
include_object=include_object
)
, но в моем случае надо будет указать не только таблицы, но еще и секвенсы и индексы. Именно в моем случае, когда у меня есть кучу проектов и все они используют только один общий модуль, это выполнимо. Так как я могу реально захардкодить все сущности БД этого общего модуля.
Но вот как на алембике писать когда у тебя в одном проекте будут использоваться много модулей со своими таблицами — вот это уже даже ума не приложу как возможно сделать.
И это второй пример, что я нашел, чем джанга лучше мира фласка.
В джанге в таблица миграций там есть несколько колонок, в том числе и названия аппликухи. Т.е. там можно вызвать миграцию не для проекта целиком, а только для его части.
Удачи сделать в джанге два аппа, требующих разные версии общей части
T
Собственно, общая часть все портит
MB
Я понятия не имею как это вообще может работать. В реальности ты все равно проект целиком только можешь деплоить
Да, конечно, мой проект деплоится целиком.
Но у меня в requirements.txt у проекта есть зависимостть типа:
my-shared-app==1.2.3
И в этом пакете есть всякое, что дает моему проекту по урлу /my-shaped-app — разные нужные штуки, которые требутся во всех моих куче проектов.
И на сервере во время обновления происходят такие команды
$ flask migrate-shared-app-up # это обновляются таблицы из общего модуля
$ flask migrate-main-up # — тут уже обновляются таблицы самого проекта
Но у меня в requirements.txt у проекта есть зависимостть типа:
my-shared-app==1.2.3
И в этом пакете есть всякое, что дает моему проекту по урлу /my-shaped-app — разные нужные штуки, которые требутся во всех моих куче проектов.
И на сервере во время обновления происходят такие команды
$ flask migrate-shared-app-up # это обновляются таблицы из общего модуля
$ flask migrate-main-up # — тут уже обновляются таблицы самого проекта
T
У тебя уже не независимые приложения
MB
Джа то, джа это, не проще остаться на джа тогда, зачем тебе фласк?
Фласк мне нужен, так как я уперся в лимиты Django ORM.
sqlalchemy позволяет мне делать больше.
sqlalchemy позволяет мне делать больше.
T
Если бы у тебя были независимые приложения, по моей ссылке описано как юзать их.
MB
Джа то, джа это, не проще остаться на джа тогда, зачем тебе фласк?
Но если джанга плоха, например, в ORM, это не значит, что в ней плохо вообще все. Мне понравилось работать с джангой. Я нашел там полезные для меня архитектурные подходы, и сейчас пытаюсь их реализовать во фласке.
T
Но если джанга плоха, например, в ORM, это не значит, что в ней плохо вообще все. Мне понравилось работать с джангой. Я нашел там полезные для меня архитектурные подходы, и сейчас пытаюсь их реализовать во фласке.
главное глобальными переменными не обмазывайся