AM
Ну каждую фичу пилит свой человек в отдельном бранче
Тогда не очень понял про локальную базу.
Size: a a a
2020 January 23
AM
Ну да, обычно сначала мержим, а потом катим. Выкатка фиче-бранча - не частая ситуация
А, теперь понятно.
KK
Тогда не очень понял про локальную базу.
Локальная база - дамп какой-то реальной базы, где есть более менее реальные данные (например с dev стенда), а не фигня из тестовых фикстур.
KK
Используется такая база, например, для локального запуска сервиса, что бы посмотреть как оно работает на реальных данных, как выполняется миграция.
AM
Локальная база - дамп какой-то реальной базы, где есть более менее реальные данные (например с dev стенда), а не фигня из тестовых фикстур.
Я про фикстуры даж не заикался :)
AM
Используется такая база, например, для локального запуска сервиса, что бы посмотреть как оно работает на реальных данных, как выполняется миграция.
Не понял только почему её надо откатывать.
AM
Используется такая база, например, для локального запуска сервиса, что бы посмотреть как оно работает на реальных данных, как выполняется миграция.
Чё-т всё смешалось. Зачем данные для миграции схемы? Если это дата миграции, то мы обычно на них тесты пишем.
KK
Ну если ты сделаешь "ребейз" миграций, то ведь может изменится порядок их выполнения. Или алембик может нормально обработать ситуацию, когда в линейном списке миграций окажется в середине "дырка" - ещё не выполненная миграция.
KK
Т.е. я в свою фиче-бранчу мержу dev ветку, и мне прилетает из неё новая миграция. Я после этого меняю в своей миграции parent_revison_id на id миграции из dev ветки - получается "дырка".
KK
И я не помню - алембик в своей таблице не хранит разве все вот эти parent_revision_id, т.е. полное дерево накаченых миграций? Если да, то он случайно не поломается, если в исходниках это дерево вдруг изменится?
DB
а вообще хранить миграции в репе - это гуд практис?
БС
И я не помню - алембик в своей таблице не хранит разве все вот эти parent_revision_id, т.е. полное дерево накаченых миграций? Если да, то он случайно не поломается, если в исходниках это дерево вдруг изменится?
нет, он хранит только последнюю ревизию что накатил
БС
Dmitry Belyaninov
а вообще хранить миграции в репе - это гуд практис?
а где же еще их хранить? На шаренном сторадже?
DB
нет, накатывать и генерить у заказчика
БС
Что значит накатывать и генерить у заказчика?
БС
ручками генерить?
DB
./manage.py makemigrations
DB
залить код. создать миграции, применить их.
KK
нет, он хранит только последнюю ревизию что накатил
При наличии бранчей в миграциях это не выглядит правильно - надо помнить по каждому бранчу последнюю накаченую миграцию. А проще просто хранить id всех миграций, которые уже применили
БС
а дата миграции? А кто их проверит?
Вот у тебя колонка переименовалась с изменением типа? Это точно ни один алембик не отследит. И вместо изменения типа и ренейма будет add column | drop column
Вот у тебя колонка переименовалась с изменением типа? Это точно ни один алембик не отследит. И вместо изменения типа и ренейма будет add column | drop column