логически привязаны к уже существующим.
Кейс: есть пользователи, уже целая база. Появляется фича оповещений, где есть настройки оповещений для каждого пользователя. Т.е. user_id, is_sms_receive, is_email_receive и прочее.
Получается на момент создания фичи база настроек пуста, а пользователи сами есть. Выходит есть проблемы с чтением, там null а не true/false ( на true/false не акцентируем, вполне могут быть и стоки и to_boolean() - не панацея) , а так же с записью, так как настройки для определенного пользователя not_found.
Какие есть варианты решения проблем? Я просто вижу, что в каждом write экшене создавать настройки пользователя, если их нет, а на чтении ставит дефолтные значения какие то.
Но получается что в каждом экшене будет проверка и создание, какой то болерплейт отчасти, а в разных частях чтения можно записать теоретически разные дефолтные значения, или вообще забыть про эту особенность.
Вариант забить всю таблицу данными на момент создания фичи - требует времени по выполнению и возможны краши пока это выполняется. Или же делать двух этапно: забить базу а потом выложить фичу в пользование?
мне кажется проще при чтении проставлять дефолтное значение, если той или иной настройки нет в БД
Миграцию накати
Миграция это самый простой вариант, но что если уже куча данных и миграция будет выполняться полчаса, час?
ты можешь сначала зарелизить скрипт для заполнения бд данными, запустить его (запомнив ID последнего юзера) потом зарелизить фичу и еще раз запустить скрипт с оффсетом этого ID чтобы дозаполнить тех юзеров, которые появились за время деплоя фичи
Проведи миграцию в самое ненагруженное время и я не думаю что пользователей настолько много что просто insert into … select id, false, false from users будет полтора часа длиться
с uuid возможно посложнее будет, но так да, вариант возможно
Зачем так сложно, просто начать для новых челов писать настройку а в след деплое добавить where not exists
Обсуждают сегодня