 Товарищи программисты. А что вы используете для отслеживания sql миграций? Чтобы аппенд онли, само номера проставляло, ругалось если какую-то миграцию изменили. И как вы решаете проблему миграций из разных веток (как их так мёрджить, чтобы они не только могли все примениться, но и последовательность сохранялась)? А то мы пока что руками это всё делаем. Это долго. За всеми программистами не уследить и вот это всё. 15 comments
 @danilax86 с мержем конечно так не получится, но имхо его лучше и не мержить.
Разработчик на тестовой базе может просто сделать копию. Пользователям это не нужно 27329ed9-2211-a1ba-9371-e2641bf0dcb6, это всё есть. Проблема в том, что вот ты делаешь свою фичу, добавил новых миграций, основная ветка за это время ушла куда-то вдаль и появились другие миграции в ней. И вот ты обновляешь свою ветку до апстрима, решаешь конфликты в коде (если есть) и понимаешь, что номера миграций теперь дублируются и нужно руками править номера или написать простенький скрипт, который делает бамп версий, чтобы и сами миграции применились и последовательность сохранилась  @danilax86 хм, технически, можно подтягивать информацию о последовательности из git-метаданных. Сохранять ее в файл пре-коммит-хуком, например. Не уверен, правда, делает ли так кто-то, и есть ли подводные камни.  > И как вы решаете проблему миграций из разных веток (как их так мёрджить, чтобы они не только могли все примениться, но и последовательность сохранялась)? Подозреваю, что для хоть сколько-то сложных случаев это все равно нужно будет делать руками - как и с кодом  @danilax86 список применённых миграций в самой бд. Номера миграций timestamp. Решаем проблему отставания просто: Миграции строго не ломающие и отдельным мр. Выкатываются заранее до релиза фичи. Если долгая с блокировками, то в тех окна.
То самое решение, о котором я почему-то не смог додуматься. Спасибо!  Миграции в рамках одного проекта прекрасно управляются фреймворком, на котором этот проект реализован. Менять миграцию, когда поверх неё уже накидали новых - это что-то из области максимально вредных советов. Так делать не надо. Надо создавать новую, исправляющую всё как надо. И чем помешали даты в названии миграции?
Но я то же самое и написал:
.
Честно, я не знаю. Эту дату ещё нужно прочитать, она ещё обязательно будет в каком-нибудь неудобном формате. Порядковый номер и очень краткое описание в названии намного лучше понимается человеком У нас если кто-то изменил миграцию ругаюсь я 😁. Но такое возможно только 1 раз на сотрудника. Потом они понимают что так делать нельзя. Не знаю зачем может понадобиться смотреть миграции подряд, я их смотрю только во время мерж-реквеста, а там их обычно пара штук.  @danilax86@friends.grishka.me у меня на работе liquibase. Мердж миграций работает почти автоматически при мердже веток, потому что он не генерирует последовательные ID, а с какой-то случайной дельтой. Из-за этого при мердже достаточно просто в index.xml убедиться, что заимпортированы и те, и другие миграции. Минусы: странности XML + странности SQL иногда рождают абсолютно непонятные ошибки парсинга, но это решается гуглежом |
Gregory's Server
Я тоже руками делаю))
Но мне ок, я же над проектом работаю в одиночестве