Всем привет, кто то сталкивался с таким кейсом. Создаю пакет

для ларавел, в проекте будут свои миграции. Мне нужно что бы миграции когда выполнялись (запускалась пользователем), сама история миграций писалась не в общую таблицу историй миграций, а в свою костюмную как например в CakePHP. Есть идеии как такое можно сделать?

php artisan make:migration create_posts_table --path=/database/migrations/posts

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

История изменений конкретной миграции?

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

если идёт речь о том, что ларавель кидает всё в таблицу migrations: там модуль миграции ларавеля юзает одну таблицу. в теории его можно заоверрайдить и сделать так, чтобы он по дефолту складировал в обычную таблицу а от либки в другую. но я не вижу ни одной причины делать это.

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

понимаю, но разделение на разные таблицы это точно не решит. там смысл в том, что оно собирает строчки из бд, сортирует по дате и выполняет down в файлах миграции. логично, если сделать несколько таблиц и привязать всё это к ядру, то оно также с них стянет миграции и также откатит всё. лучше сделать отдельную либку, которая разделяет всю пачку миграций на отдельные "потоки". механика та же: оверрайдим класс с миграцией и опрашиваем все либки (там в package.json в extra можно что-то запихать для идентификации), разделяем на "модули/потоки" миграций и откатываемся как хотим.

PS у меня на одном проекта примерно та же проблема, но в другом ключе (что ларка очень плохо в модульность). решили просто через несколько инстансов ларавеля, скоро будет перетаскивать всё это на симфони

доктрина так умеет ... в нашей вариации пакетов под симфони это решено

ну ты клиенту не объяснишь что под каждый пакет нужно отдельный "микросервис"

welp. тогда, решение только одно: сносим часть с миграцией ларавеля и приклеиваем миграцию от того, что больше нравится и работает) PS команду можно снести через провайдер, а лучше перезаписать её и кидать эцепшн с поясняловкой, что надо запускать другую команду чтобы было всё норм

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

я понимаю что хочется сделать, но в ларке такого нет. есть класс Illuminate\Database\Migrations\Migrator именно он отвечает за миграцию и откат, можно с ним немного поколдовать и перезписать в сервис провайдере либки (которая будет грузится после ядра и будет перезаписывать ссылку на этот класс для инжектора на твой кастомный, тем самым, изменяя механику дефолтной команды) я бы в таком случае оставил таблицу миграций и добавил бы туда nullable колонку module:varchar и по ней бы получал миграцию модуля и его "локальную" историю и записывал бы туда название модуля из композера при накате миграции но это всё звучит как костыль

кажется, его решают через migrate:fresh XD

а как пакеты под ларавел, что никто не пишет свою историю миграций?

пишут. чаще всего пакеты любят делать команду ./artisan shit:install или ещё что-то и тупо копируют свои миграции тебе в папку с миграциями

@lucky_950 ты про этот вариант ?

Да да

для того что бы его сделать мне нужно больше знаний, я его не откидываю, но и пока считаю что не самый легкий путь