ммм а это точно миграции? может у тебя под видом мигграций какой-нибудь импорт данных приложения идет?

Например я хочу перекинуть каких-то юзеров в другую группу. Или роли присвоить им.

у него не две разные базы в рамках одной аппликухи

Утрировано.

Например я хочу перекинуть каких-то юзеров в другую группу. Или роли присвоить им.

это НЕ миграции

делай просто CLI команды

миграции должны удовлетворять простому требованию

ты можешь откатиться на любую ревизию гита и накатить миграции и они должны накотиться

А зачем для одноразового изменения команда?

А зачем для одноразового изменения команда?

потому что миграции не для одноразового изменения)

каких к черту заказкичов?

у него по этому принципу делается различие в том, что и где выполнять

Так ты можешь. В даун переносишь обратно.

Так ты можешь. В даун переносишь обратно.

не можешь

Обоснуй. :)

Так ты можешь. В даун переносишь обратно.

чаще всего после обновления данных восстановить исходные невозможно

update field set value = 100;

и потом у тебя опа, в поле 100

это ты прописал или аппликуха после деплоя написала?

Вот конкретная задача. Всем клиентам с пакетом премиум, дать роль Вахтёр.

миграции - это только поддержание схемы базы в актульном состоянии. Все. Точка. Если тебе надо данные чето там как-то сделать - это не миграции

любая конкатенация - теряешь оригиналы

Вот конкретная задача. Всем клиентам с пакетом премиум, дать роль Вахтёр.

bin/console doctr:query:sql $sql

Это не проревьюить.

Это не проревьюить.

папочку с sql-ками сделай если хочешь

А в даун у всех с премиумом роль вахтер убрать.

но это НЕ миграции

Это не проревьюить.

sql в файлик и прекрасно ревьюится

Вот мне кажется это как раз усложнение.

Или я не прав?

зависит от того, насколько строго у тебя в проекте к этому относятся

Или я не прав?

если это усложнение - то почему у тебя тогда проблемы сделать так как "тебе кажется проще"?

Нет проблемы. Я спросил есть ли готовое решение. ;)

если делать в виде миграций - skipIf

а мы уточнили зачем и получили ответ что тебе не для миграций это надо (schema migrations они называются) а для того что бы одноразовые штуки делать

а там или имя хоста проверяй, или значение переменной из env - не суть

если делать в виде миграций - skipIf

Надо наоборот правило не скип иф. :)

Иначе с ростом числа клиентов будет все хуже.

->skipIf(gethostname() != 'foo')

не суть

А ну да. :))

Иначе с ростом числа клиентов будет все хуже.

когда у тебя по базе на клиента ты уже как бы роешь себе ямку

какая разница что будет в skipIf - равно или не-равно?)

когда у тебя по базе на клиента ты уже как бы роешь себе ямку

Например?

что значит "например"?)

p.s. у меня есть опыт работы с вайтлейблами по такой схеме если тебе интересно)

когда у тебя по базе на клиента ты уже как бы роешь себе ямку

Схемы и приложения не будут отличаться вообще. Только данные само собой.

p.s. у меня есть опыт работы с вайтлейблами по такой схеме если тебе интересно)

Интересно. :)

Схемы и приложения не будут отличаться вообще. Только данные само собой.

так зачем разные инстансы?

так зачем разные инстансы?

Чтобы не париться с разграничением данных.

конфигами разрулил различия и привет

Чтобы не париться с разграничением данных.

ты уже начал париться с разграничением данных))

Чтобы не париться с разграничением данных.

как сладко когда 1 деплой превращается в 20

или 100

ты пришел с вопросом "как разграничить модификацию данных"

что есть ни что иное, как разграничение

ты уже начал париться с разграничением данных))

Только однажды. Миграции обычно - достаточно простые и самостоятельные.

дело не в миграциях, а в том, что выбрав между разными инстансами и разграничением данных ты получил и инстансы и разграничение))

сейчас тебе надо только данные модифицировать

потом тебе надо будет заголовки специальные слать

потом иерархию ролей другую

потом еще что-то

Этторе составляет проблемы репу форкнуть в таком случае.

у тебя будет столько вариантов приложения, сколько клиентов)

репу форкнуть - дело не хитрое

Просто никакой опасности случайно показать данные одного клиента другому.

а вот суппортить несколько проектов, которые отличаются в каких-то мелочах - это ад

а про мелочи эти помнит только один человек

Если например данные финансовые какие нибудь.

ERROR: S client not available

а его вчера сбил автобус

и привет

Ну я уж просто приукрасил.

Считай это как одно одинаковое для всех приложение.

так а я нет :)

Все что будет отличаться, будет только в конфигах. Либо в данных.

Соответственно заголовки или че - можно туда же засунуть.

это сейчас)

Ну ты можешь какой-то реально проблемный случай предсказать?

Ну ты можешь какой-то реально проблемный случай предсказать?

у меня была только боль управления инфраструктурой.... но в целом это не так страшно как другие "типичные решения" которые люди с вайтлейблами выдумывают

Ну как-то ее все равно надо решать же. :)

Есть ли более элегантное решение тогда?

решение чего именно?)

Ну как-то ее все равно надо решать же. :)

ну у нас все было автоматизировано. а так решение одно - по больше всего держать для всех в единственном экземпляре

миграций, обновления данных или интансов?)

ему не миграции нужно делать

ну у нас все было автоматизировано. а так решение одно - по больше всего держать для всех в единственном экземпляре

но с бэкапами)))

ему таски приходят в духе "эй, там надо для вайтлейблов А и Б залить данные, на другой друггие"

но с бэкапами)))

а что с ними?)

ну у нас все было автоматизировано. а так решение одно - по больше всего держать для всех в единственном экземпляре

Я если честно не хочу париться с «if account === blabla”

Я если честно не хочу париться с «if account === blabla”

ммм а оно и не надо)

Где-то забудешь, и все увидят то, что не надо. :)

а что с ними?)

к ним "в единственном экземляре" часто неприменимо)

но тебе где-то этот if надо держать

в голове, на уровне запуска команды, на уровне конфигов

к ним "в единственном экземляре" часто неприменимо)

ммм.... почему? пул бэкапов это "один экземпляр"

Где-то забудешь, и все увидят то, что не надо. :)

так и при конфигурировании тоже можно забыть разделить и все всё увидят)

но тебе где-то этот if надо держать

Но если это разные инстансы и сервера - по определению такого не будет.

так и при конфигурировании тоже можно забыть разделить и все всё увидят)

Так машины разные.

На этой машине тех данных нет.

Они на другой

Но если это разные инстансы и сервера - по определению такого не будет.

смотри. Вот на нашем проекте типа все в одной базе, и тут вжух приходит клиент из какой бразилии и там по законодательству данные пользователей должны хоститься на територии страны.