У меня есть два проекта Laravel: один для клиента (назовем его project A), а другой — для администратора (назовем его project B).
Если я обновляю базу данных, например, создаю новую таблицу или добавляю дополнительный столбец в существующую таблицу, используя миграцию Laravel из project B, требуются ли какие-либо действия на стороне project A?
Благодарю вас!
Вы можете создать first_migration в project A и выполнить его, а затем создать second_migration в project B и выполнить его, вы обнаружите, что миграции работают, как и ожидалось.
Но... когда вы пытаетесь выполнить rollback миграции в любом из проектов, вы можете получить ошибку Migration not found, поскольку действие rollback вызовет метод down в каждом перенесенном файле миграции, но project A или project B имеет часть всех файлы миграции.
Таким образом, вы можете собрать все файлы миграции вместе, используя --path:
php artisan make:migration foo --path="../projectB/database/migrations"
# or
php artisan make:migration foo --path="/the/absolute_path/to/projectB/database/migrations" --realpath
# migrate
php artisan migrate --path="../projectB/database/migrations"
# migrate:rollback
php artisan migrate:rollback --path="../projectB/database/migrations"
Если вы войдете в свою базу данных и выполните select * from migrations, это должно помочь вам увидеть, на что ссылается команда artisan migrate, чтобы решить, запускать ли миграцию.
Я просто подумаю с тобой:
Если вы создадите миграцию в проекте A и запустите ее, она обновит вашу базу данных, а таблица миграции в вашей базе данных запишет, что миграция была выполнена.
Проект B не будет иметь эту миграцию в своей собственной папке базы данных/миграции в приложении. Поэтому, если вы сделаете artisan migrate --pretend, реальность такова, что в таблице миграции будут найдены записи, о которых нет записи в виде файлов миграции в собственной папке базы данных/миграции.
Я на самом деле не уверен, что он там будет делать.
Но иметь одну базу данных, используемую несколькими приложениями, определенно разумно, что вы пытаетесь сделать здесь. Это нормальная практика.
Почему бы просто не решить, какое приложение, A или B, вы собираетесь возложить на себя ответственность за проведение всех миграций, и знать, что вы когда-либо будете выполнять только artisan make:migration и artisan migrate, скажем, в проекте A, и просто рассматривать проект B как второго клиента базы данных, которой на самом деле «владеет» проект A?
Итак, учитывая вышесказанное, ответ на ваш вопрос, я думаю, нет. Вам не обязательно использовать систему миграции в приложении laravel. С таким же успехом вы можете подключиться к базе данных и предположить, что все таблицы, которые нужны вашему коду, уже там, что и будет делать ваш проект B.
(Но может иметь смысл, чтобы ваша сторона администратора была владельцем миграции базы данных (которую вы на самом деле назвали проектом B выше)).
Также очевидно, что при использовании красноречия обоим проектам потребуются соответствующие красноречивые модели. По крайней мере, вам придется продублировать этот код.
