gо
Разработку они тоже усложняют, потому что тебе ещё и локально у каждого разработчика нужно выстраивать правильный стейт базы
Size: a a a
2021 May 26
gо
Я пока не видел систем миграций, которые хорошо, честно поддерживали бы хранимки
DS
Ну перенакатывать все всегда
DS
Единственный выход, на самом деле
gо
Мгхм.
Наживую?
Наживую?
gо
Т. е. ты на продовой БД удаляешь хранимку а потом добавляешь?
gо
А в промежутке у тебя юзеры дохнут или ты всю БД лочишь?
gо
На каждом релизе?
DS
Это только в том случае, если можно всё залочить на релизе, само собой
gо
Это разве что версионировать в названии и со стороны кода это как-то поддерживать
DS
Если такой возможности нет, то всё боль - да, тут согласен
SS
Я прост хочу в сторону бекенда двигаться, а там много нюансов не связанных напрямую с хттп-фреймворком, поэтому интересно очень
gо
В принципе, можно придумать такую систему
SS
CREATE OR REPLACE?
gо
Но для этого нужен очень умный мигратор, который работает в паре с тем-что-там-у-тебя-для-SQL, чтобы в самом коде не было
моя_супер_хранимая_процедура_v47gо
А ты сначала раскатываешь код или меняешь хранимки?
gо
В любом случае, у тебя код работает с неверными хранимками тогда некоторое время.
gо
Это именно что нужно лочить всю базу на всё время апдейта.
YM
парадигмы существуют, чтобы решать какую-то проблему
вот разные парадигмы решают одну проблему или разные?
вот разные парадигмы решают одну проблему или разные?
DS
Ну я как раз про такой вариант говорил. Там где базу лочить нельзя - там да, хранимки обновлять дико сложно корректно