ŹR
Size: a a a
2020 October 20
ŹR
А почему это реально?
ŹR
Меняешь имя колонки, ключи, типы - десять тысяч раз в каждом проекте
ŹR
Это все обратно не совместимо
B
А если руками - то что, ты руками стопишь все свои сервисы?
ну так если миграция новая и они работают с этими новыми данными разве их не нужно стопить? А если изминения в миграции их не касаются то и фиг с ними.
AM
Меняешь имя колонки, ключи, типы - десять тысяч раз в каждом проекте
не меняй а добавляй новые например
AM
ну в общем я хз, у нас так все работали, но я в той компании приложения не писал, а тестил
ŹR
не меняй а добавляй новые например
Это превращается в трехступенчатые комбины
ŹR
Короче я не встречал ещё стартапов, которым бы не было впадлу этим заниматься
AM
если ты на стадии move fast, может и стопнуть на пять минут все контейнеры не так уж и плохо тогда
ŹR
Люди не могут через полгода даже консистентность сохранить у самих миграции
B
а так как по мне лучше пусть будет единый сервис который работает с БД, остальные пусть ему в очередь сгружают
B
а так если каждый что-то там пишет, можно быстро заебаться
ŹR
Сервис то единый, а вот инстансов у него много
B
Вгрузил новую миграцию руками, адпейтнул релиз.
B
ну будет у тебя минута простоя
B
Там же так или иначе инстансы же нужно будет перезапускать если ты миграцию меняешь.
B
ибо как это будет работать?
AB
Меняешь имя колонки, ключи, типы - десять тысяч раз в каждом проекте
не, ты ничего не меняешь. только добавляешь новое(и изредка удаляешь старое)
а вообще, про это наверное нужно книжки поискать, что-то такое должно быть
а вообще, про это наверное нужно книжки поискать, что-то такое должно быть
SK
Это превращается в трехступенчатые комбины
Если тебе даунтайм нельзя, то там всегда начинаются велосипеды. Добавил новую колонку; выпустил новую версию кода, чтобы данные и туда и туда писались; потом выпустил новую версию, которая пишет только в новую колонку; потом дропнул старую колонку.