I have two Laravel projects, one for client-facing (let's call this project A) and the other one for admin (let's call this project B).
If I update database, such as creating new table or adding extra column on existing table, using Laravel migrate from the project B, is there any action required on project A side?
Thank you!
You can create the first_migration in project A and excute it, and then, create the second_migration in project B and excute it, you will find the migrations are work as expected.
But...when you try to rollback the migrations in any of the project, you might get a Migration not found error, due to the rollback action will call the down method in each migration files which had migrated, but project A or project B has part of all migration files.
So, you might put all your migration files together by using --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"
If you go into your database and do select * from migrations that should help you see what the artisan migrate command is referencing to decide whether to run migrations.
I'll just think it through with you:
If you create a migration in project A and run it, it will update your database and the migrations table in your database will record that the migration has been run.
Project B isn't going to have that migration in its own database/migrations folder in the app. So if you do artisan migrate --pretend the reality is its going to find entries in the migration table which it has no record of as migration files in its own database/migrations folder.
I'm not actually sure what it would do there.
But having a single database used by multiple apps is definitely a reasonable thing you're trying to do here. It's normal practice.
Why not just decide which app, A or B, you are going to make responsible for holding all migrations and know that you'll only ever do artisan make:migration and artisan migrate in, say, project A, and just consider project B to be a second client of the database which project A actually "owns"?
So, given the above, the answer to your question I think is no. You don't have to use the migration system in a laravel app. You can just as well connect to a database and assume that whatever tables your code wants are already there, which would be what your project B would do.
(But it might make sense to have your admin side be the owner of the database migrations (which you actually called project B above)).
Also obviously if using eloquent then both projects are going to need the respective eloquent models. You'll have to duplicate that code at least.
