AM
Если всё будет конфигурируемое будет слишком сложно, всё будут toml программистами.
Size: a a a
2020 January 23
AM
Dmitry Belyaninov
эммм, ну если все модели зафигачить в одно приложение...
Лично я не вижу ничего плохого чтобы просто разрабатывать одно большое приложение на целый проект. Но так опять же не принято.
KK
Dmitry Belyaninov
но ок, поверю. хотя странно что с этим проблемы и нет такой фичи, удобно и нет проблем с зависимостями миграций например
Проблем с зависимостями нет только если ты один и в одном бранче пилишь код. А когда несколько человек и несколько фиче-бранчей - то миграции будут тоже витвиться.
И на самом деле гораздо удобнее когда миграции лежат рядом с теми моделями, которые они мигрируют, а не всё в одну кучу - сиди потом и ищи где какая миграция.
И на самом деле гораздо удобнее когда миграции лежат рядом с теми моделями, которые они мигрируют, а не всё в одну кучу - сиди потом и ищи где какая миграция.
ИК
Можно alembic'ом мигрировать Django приложение 😁
Очень жалко, что в alembic не сделали, что бы имя файла как-то указывало на порядок миграции...
KK
Это, если посмотреть более широко, по сути та же "инкапсуляция" и "принцип одной ответственности" - миграции джанго приложения "сокрыты" внутри этого приложения и нет одной супер-папки, которая отвечает за миграции всех приложений.
KK
Очень жалко, что в alembic не сделали, что бы имя файла как-то указывало на порядок миграции...
Имя файла в алембике можно настраивать как тебе угодно (там можно по моему функцию даже указать). Я например генерил его как-то так YYYYMMDDHHMM_some_description.py
ИК
Имя файла в алембике можно настраивать как тебе угодно (там можно по моему функцию даже указать). Я например генерил его как-то так YYYYMMDDHHMM_some_description.py
Да? Пойду почитаю.
KK
И в алембике есть команда которая позволяет вывести в консоль дерево миграций с учётом их порядка и ветвистости
KK
Да? Пойду почитаю.
Сейчас вот смотрю свою интеграцию с алемдиком и не могу найти где я это настройл. Но все миграции у меня вот в том формате как я указал
KK
А, нашёл - это в ini файле у меня задано
[alembic]
# template used to generate migration files
# default: %%(rev)s_%%(slug)s
file_template = %%(year)d%%(month).2d%%(day).2d%%(hour).2d%%(minute).2d%%(second).2d_%%(slug)s
AM
Проблем с зависимостями нет только если ты один и в одном бранче пилишь код. А когда несколько человек и несколько фиче-бранчей - то миграции будут тоже витвиться.
И на самом деле гораздо удобнее когда миграции лежат рядом с теми моделями, которые они мигрируют, а не всё в одну кучу - сиди потом и ищи где какая миграция.
И на самом деле гораздо удобнее когда миграции лежат рядом с теми моделями, которые они мигрируют, а не всё в одну кучу - сиди потом и ищи где какая миграция.
Правило хорошего тона ребейзить не только ветки Гита перед мержем, но и миграции.
KK
А если фиче-бранч уже прокатили на dev стенд, и миграцию применили? Тут уже не заребейзишь - миграция заново запустится на dev стенде
AM
А если фиче-бранч уже прокатили на dev стенд, и миграцию применили? Тут уже не заребейзишь - миграция заново запустится на dev стенде
Эм... У вас все заделоенные фиче бранчи во время разработки в одну и туже базу смотрят?
БС
А, нашёл - это в ini файле у меня задано
[alembic]
# template used to generate migration files
# default: %%(rev)s_%%(slug)s
file_template = %%(year)d%%(month).2d%%(day).2d%%(hour).2d%%(minute).2d%%(second).2d_%%(slug)s
вот этот формат удобнее
добавляется еще и айди ревизии. Тоже иногда нужно.
file_template = %%(year)d%%(month).2d%%(day).2d_%%(hour).2d%%(minute).2d_%%(rev)s_%%(slug)s
добавляется еще и айди ревизии. Тоже иногда нужно.
KK
Эм... У вас все заделоенные фиче бранчи во время разработки в одну и туже базу смотрят?
Да, у нас почти никогда фича не выкидывается из релиза, а потому нет неодходимости базу откатывать. Кроме того у разработчиков может быть локальная версия базы, которую, в случае ребейзов миграций, придётся каждый раз перекатывать из бекапов.
KK
Ну и польза ребейзов в данном случае такая же "сомнительная" как и в git-е. Чисто эстетическая. Хотя конечно могут быть кейсы с конфликтами, но у нас такого не было. Это надо наверное что бы две фичи требовали создание или изменение в таблице одной и той же колонки.
AM
Да, у нас почти никогда фича не выкидывается из релиза, а потому нет неодходимости базу откатывать. Кроме того у разработчиков может быть локальная версия базы, которую, в случае ребейзов миграций, придётся каждый раз перекатывать из бекапов.
Фиче бранч пилят несколько человек?
KK
Ну каждую фичу пилит свой человек в отдельном бранче
RH
Если дев стенд один с одной базой, разве удобно на него катить разные фичеветки? Не проще для начала мержить фичеветки с предварительным ребейзом миграций при необходимости в одну дев ветку?
KK
Ну да, обычно сначала мержим, а потом катим. Выкатка фиче-бранча - не частая ситуация