Вариант 1 — вторая ветка не имеет новых миграций для этой базы.
Миграцию выполнять не нужно. Проблемы нет.
Вариант 2 — во второй ветке есть невыполненная миграция. При ее выполнении будет создано новое состояние базы, которое не будет воспроизведено нигде. (результат мержа этих двух веток не всегда будет совпадать с результатом работы каждой из них отдельно выполненной в произвольном порядке)
Если обе меняют схему в БД — откатили и накатили другую.
Если нет — можно и так. По быстрому.
Если же по нормальному — нам нужно работать с тем же состоянием и не создавать себе проблемы с хранением в голове веток, их миграций, взаимосвязей в коде и в базе. Лучше эти ресурсы потратить на разработку самой фичи, и концентрацию на ней.
Изменения в ветке вы же тоже комитите или сташите, логично, что изменения в базе тоже нужно откатить. По этому у вас и есть down миграции.
Иначе как понять состояние базы, если база считает, что была миграция, а кодовая база не знает что в ней было, следовательно не понимает в каком состоянии база, и совпадает ли это состояние с кодом.
Там есть возможность перенакатить базу с форсом. Если это имеет смысл и локальный стейт не содержит нужных данных, или есть подготовленные скрипты наполнения базы случайными данными.
У мигрейта есть схожая функциональность. Можно указать на сколько шагов нужно откатить базу. Но при наложении миграций, или мерже «вчерашних» — он не сообщает о проблемах, что создает дополнительные риски при релизе.
github.com/rubenv/sql-migrate
Вот рабочий вариант миграций с атомарностью и раздельным хранением.
Не так популярно, как go-migrate, но мне тож так больше нравится. (не только верхняя версия, а весь список примененных миграций к конкретной БД и когда они были выполнены.)
Из плюшек — миграции вшиваются в бинарник, и деплой базы упирается в указание, какая из нод должна накатить изменения. Требования обратной совместимости и не мигрировать всеми разворачиваемыми нодами одновременно естественно на релиз инженере. github.com/lancer-kit/service-scaffold/tree/master/dbschema — пример интеграции.
(надеюсь, что не обидел автора топика разместив ссылки в комментариях)
quickblox.com/ — Харьков Украина, работают. habrahabr.ru/post/231747/ — Одесса если не ошибаюсь. Украина.
Вообще на Украине есть очень интересные проекты, есть хорошие начинания, есть даже разработка проектов под кикстартер в качестве аутстафа.
Хотя да — привкус золотой лихорадки тоже есть:(
Хм, предложение создания интросети — по сути в таком ключе глупость,
т.к. сражаться для целостности населения нужно с ответственностью, а не с самим доступом, агенты влияния могут действовать и внутри изоляции.
По сути — им нужно наоборот — просвещение, свободный доступ, и единая система авторизации, с регистрацией по документам + идея ее популяризации. К открытости и деанонимизации люди должны прийти сами.
Вопрос же на международном уровне влезть в развитие интернета, становление технологий, и при необходимости отстаивать интересы граждан…
В свое время несколько раз так попадал, после чего вывел для себя простое правило — «как можно чаще задавать себе вопрос — а сколько стоит для меня данная выгода?»
Ок. Вопрос будет только в откровенности людей, и их психике. Сейчас и так с этим траблы. С таким подходом можнно упростить, подходишь, вынимаешь табличку — «я злой», а в ответ тебе — «а я тебя понимаю», ты в ответ — «беру». Вопрос в том, что импланты должны расширять возможности человека, а не лениво выдавать ему их…
А если человек работает продавцом каждый день — ему что негде брать опыт? или чистый сурагат вместо навыков? так там просто графики и однозначные ответы не подойдут:)
Вопрос только 1 — зачем. Те же навыки можно получить тренингом, ничего сложного, и времени уйдет не больше, чем на операцию. Да и визуальный ряд портить не нужно. Если человек будет вечно вместо лиц видеть графики — у него скорее всего начнутся проблемы с психикой. Да и покупателям будет вряд ли комфортно… Делать что либо белее интересное — это да. А на старые «добрые» торговые отношения между людьми наворачивать еще и импланты — не интересно…
Нужно еще учитывать что таких проводников рядом большое количество, и при прохождении импульса по надцати сонаправленным нейронам результат будет интереснее;)
Миграцию выполнять не нужно. Проблемы нет.
Вариант 2 — во второй ветке есть невыполненная миграция. При ее выполнении будет создано новое состояние базы, которое не будет воспроизведено нигде. (результат мержа этих двух веток не всегда будет совпадать с результатом работы каждой из них отдельно выполненной в произвольном порядке)
Если обе меняют схему в БД — откатили и накатили другую.
Если нет — можно и так. По быстрому.
Если же по нормальному — нам нужно работать с тем же состоянием и не создавать себе проблемы с хранением в голове веток, их миграций, взаимосвязей в коде и в базе. Лучше эти ресурсы потратить на разработку самой фичи, и концентрацию на ней.
Иначе как понять состояние базы, если база считает, что была миграция, а кодовая база не знает что в ней было, следовательно не понимает в каком состоянии база, и совпадает ли это состояние с кодом.
Там есть возможность перенакатить базу с форсом. Если это имеет смысл и локальный стейт не содержит нужных данных, или есть подготовленные скрипты наполнения базы случайными данными.
У мигрейта есть схожая функциональность. Можно указать на сколько шагов нужно откатить базу. Но при наложении миграций, или мерже «вчерашних» — он не сообщает о проблемах, что создает дополнительные риски при релизе.
Вот рабочий вариант миграций с атомарностью и раздельным хранением.
Не так популярно, как go-migrate, но мне тож так больше нравится. (не только верхняя версия, а весь список примененных миграций к конкретной БД и когда они были выполнены.)
Из плюшек — миграции вшиваются в бинарник, и деплой базы упирается в указание, какая из нод должна накатить изменения. Требования обратной совместимости и не мигрировать всеми разворачиваемыми нодами одновременно естественно на релиз инженере.
github.com/lancer-kit/service-scaffold/tree/master/dbschema — пример интеграции.
(надеюсь, что не обидел автора топика разместив ссылки в комментариях)
habrahabr.ru/post/231747/ — Одесса если не ошибаюсь. Украина.
Вообще на Украине есть очень интересные проекты, есть хорошие начинания, есть даже разработка проектов под кикстартер в качестве аутстафа.
Хотя да — привкус золотой лихорадки тоже есть:(
т.к. сражаться для целостности населения нужно с ответственностью, а не с самим доступом, агенты влияния могут действовать и внутри изоляции.
По сути — им нужно наоборот — просвещение, свободный доступ, и единая система авторизации, с регистрацией по документам + идея ее популяризации. К открытости и деанонимизации люди должны прийти сами.
Вопрос же на международном уровне влезть в развитие интернета, становление технологий, и при необходимости отстаивать интересы граждан…