MR
Звучит как придуманная проблема на ходу)
Size: a a a
2021 October 08
SG
Вот кстати, у тебя получается что таблица накаченных миграций есть только на основном окружениии (дефолтном)
SG
Короче - тут явно что-то не так
SG
Может быть проще запускать миграции с ключом
SG
Посмотри есть ли у artisan migrate ключ --connection
e
Я смотрел
MR
Можно создать свою migrate комманду, и в handle запускать оригинальную с ключом connection
e
Просто миграции как тогда, по папкам для разных бд
SG
В общем я бы советовал пересмотреть логику мигрирования
SG
Нет, не в разных, просто запускаешь мигрейт под разными окружениями
e
просто структура же разная для разных бд может быть
SG
Покажи пример такой миграции
MR
Условия в коде придумали в 1981
Люди до 1981:
Люди до 1981:
e
Eсть миграция которая только к 1 базе применяет
Есть миграция которая сразу к 2, есть которая вообще к другой
Есть миграция которая сразу к 2, есть которая вообще к другой
e
Если запущу с ключом —conenction то все миграции выполнятся для каждой базы
SG
То есть у тебя есть условная миграция add_column_to_table_on_connection2, при выполнении которой в таблицу миграций connection1 запишется твоя миграция как выполненная?
e
У меня есть основная база, ядро, в нее записываются все миграции которые прошли.
В самих миграциях используется конструкция DB::connection()
Где может стоять любое из подключений в клюбом количестве.
В самих миграциях используется конструкция DB::connection()
Где может стоять любое из подключений в клюбом количестве.
SG
Я бы вынес миграции в отдельный проект