I have a migration file in a Laravel project that sits on a slightly-older branch. In newer branches, newer migrations have been created and ran in production. I have ran the migration in my local environment, but in no other environment.
What will happen if I need to push this migration to the master branch, then to production? My assumption is that it will just not run since a newer migration has run, but that is an assumption.
What is the best way to handle something like this? I could not find anything clear in the laravel documentation for Laravel 5.6.
My assumption is that it will just not run since a newer migration has run, but that is an assumption.
Laravel tracks which migrations it has run in the database's migrations table. If a migration is in the directory and hasn't been run before, it will get applied next time artisan migrate is run, regardless of the fact that "newer" migrations have already been run. The migration code is not inherently aware of dates; it's running the migrations in filename order, as you can see in the relevant code.
Related
I wanted to update my existing data that are added through seeds (like change permissions,etc.) on the production server. I've created migration for changing the data as per the requirement.
I've also written unit tests for my code that are configured to run automatically through bitbucket pipelines when I am pushing anything on my repository.
So the problem is when tests are running it runs migration first then running the seeds.
But when migration is running my tests are getting failed cause of altering existing data because seeds didn't run at that time and data is missing.
Just a quick one really
I have an existing Laravel app
I want to use a migration to add some columns to an existing table
So i do the following:
php artisan make:migration add_columns_to_table
Which creates a file in my migrations folder called:
2017_10_25_124938_add_column_to_table.php
And also creates an entry in my migrations table in the database. All good.
I can edit the migration file (adding the columns etc) and run
php artisan migrate
And everything works great
Now - my question is this:
When i come to deploy to live i am presuming I would log onto the live box and run the create migration command again:
php artisan make:migration add_columns_to_table
But this will create a migration with a different name to the one i created / tested locally?
So - do i then need to manually copy the code from my local 2017_10_25_124938_add_column_to_table.php migration file to the one created on the live box?
That seems a bit backwards and fiddly
What is the best way of creating and testing a migration locally and then deploying it to live when the create migration command creates a different named migration file (and DB entry) on the live box?
Or have i got the wrong end of the stick?
The best practice is to keep migration files with the repo. While deploying the application on any environment you have to execute all migrations.
php artisan migrate
This command will run all the migrations which are not already executed in the current environment. Laravel use a table called 'migrations' to keep track of all the migrations it has run.
In my deployment strategy I want to do the following:
Get code from git
Install dependencies via composer (dev requirements as well)
Run tests (phpunit etc)
Install dependencies for production (will remove dev requirements)
Zip
Copy to server
Unzip
Change symlink to current release (leave 2 old releases in case of revert)
At this point can I run php artisan migrate to update the database?
Considerations:
The application cache files are purged (actually they are empty like a fresh install).
Will the migrate query check the schema to know if updates are required?
All in all:
Can I run php artisan migrate safely in production with no previous application cache?
How does the migrate task kow the history of the table and what needs to be done?
When you first run your migrations, Laravel creates a migrations table which helps it to know at what point you are with your migrations.
I suggest doing always a backup, anyway you can update your tables without any issue if you test them locally before applying them in production and, most important, you don't edit the old migrations but instead add new ones to migrate, event to edit existing tables (add/remove columns).
PS: Why would you need to symlink if you use git? I'd just tag a working release.
If you are able to get ssh access to your hosting server, even a sandboxed version to just be able to access your site folder, you may directly deploy using git. Best way to avoid any problem caused by a failing copy of files.
I am just beginning to learn laravel and so I am constantly dealing with migration methods right now. Previously, I have deleted a migration file ShippedViaToPurchaseOrders and after that I cannot perform php artisan migrate:reset/rollback anymore. What is the problem with this? Please help. Please take a look with the error below. Thank you so much.
These files are loaded using composer, it still thinks the file is there.
Try running the composer dump-autoload command before running migrations to recreate the autoload file and let composer know the file is no longer there.
Update:
The Laravel migration tool creates a table migrations in your database to know what migrations have been executed. In this table, remove the row corresponding to the removed migration.
Because the row is still there, Laravel will keep trying to run the rollback migration corresponding to that row.
I have 38 migration script that I wrote in Laravel 4.
I don't want to throw them away, but I also don't want to run them either. I just want to keep them as references.
If I place them in the migration folder in Laravel, it will run when I do
php artisan migrate and that will break some part of my database, as they have already been run.
I'm wondering if there is a way to mark them as already run, so Laravel will not trying to run them again.
I notice the migration table in my database - can I do something with it ?
What is the best way I should do to those 38 migrations ? Feel free to give me any suggestions.
Your question is a little confusing -- Laravel will only run each migration once. It keeps track of which migrations have run in the migrations table. The whole idea of migrations is a series of date sortable scripts that you can run at anytime start to finish and they rebuild your database, AND that you can add to without needing to rerun them all as they work (so your data is preserved)
If you're running
php artisan migrate
and Laravel's running a migration it has already run, something is very broken with your system.
(Speculation follows) It seems more likely the latest migration you're running may have halted half way though in a place MySQL couldn't rollback the changes, and Laravel's trying to rerun the latest one. Try a
php artisan migrate:rollback
Fix the error in the breaking migration, and you'll be all set.