I am having a very bad situation here, working on a Laravel 5 project. previously developed by another developer. That developer at start created couple of tables using migration generators and added some columns using migrations. After that, he added table columns straight away using some sql GUI. I was given the sql dump which i imported and set it up on my local machine, now when i created a table using php artisan make:migration create_myTableName_table --create="myTableName" the table migration is created successfully, but, when i did php artisan migrate it's giving me SQLSTATE[42S01]: Base table or view already exists: 1050 Table 'someTable' already exists I checked migrations folder and matched it with current version of someTable and i can see the columns are different, same with other tables aswell.
What should be the best case to handle this in this situation, i want to keep up with Laravel migrations generator so that in future if any other developer want to work on this project he just has to run migration command to migrate database or to create tables or create columns... Should i re-write all migrations ? pleas help. Thanks
Given your situation, I’d put the .sql export in your repository, clear out the old, broken migrations, and create a new one that initially imports the database dump. Then just create migrations as normal going forward.
Quick and dirty?
Delete current migration files. Clear your migrations table and export the whole DB. Put the SQL dump in the repo and instruct other devs to import it before they run php artisan migrate. With the dump imported and migrations table truncated, you can create new migrations with no further collisions with the legacy migrations.
Feeling ambitious?
Use a package like migrations-generator to generate migrations based on your current DB structure. Then, migrate away.
Related
I have a site in development so database structure is still in flux. If I run migrate:reset, this rollbacks all migrations. Am I, therefore, okay to amend the migrations - i.e. amend Schema closures and remove migration files etc - as opposed to adding more migrations to amend the DB structure? For example, client asked for certain functionality requiring a table, decides later he doesn't want it so I have a table in my migrations I will never use. Ideally I don't want this to appear in my migrations.
If you don't need a table anymore in your project of course you can delete it's migration file.
When you run php artisan migrate:reset Laravel rolls back all migrations. But if you delete your migration file without rolling it back, Laravel will try to find that migration file to roll it back and when it can't find that file; it will throw an exception.
In such cases you can use php artisan migrate:fresh
With migrate:fresh Laravel doesn't try to find and roll back migrations, it just drops all tables and starts a fresh migrations table and migrates every file from start.
So; if you have changes on your migration files, anything, and if you are on development enviroment and nothing will affected: you can do whatever you want with your migration files and run php artisan migrate:fresh to drop every table and migrate them again.
Please check here: https://laravel.com/docs/8.x/migrations#rolling-back-migrations
Have been using Laravel for over a year now. My migrations folder has 39 files at the moment and i work (construct/destroy) with my database occasionally.
What happens is since ive created a "create_payments_table" migration, every migrate command that i execute builds all my tables normally but when login the migration history to my migrations table it stops at the 'create_payments_table' migration. So now when i create new migrations and run migrate again it tries to restart from my payments table which already exists giving me an error. Comparing my "create_payments_table" migration with the last logged migration file "create_pictures_table" it seems that everything is in order. Would like to know why my migrations create the tables but not all of them are been logged in migrations table?
My migrations table:
My migrations folder:
As u can see i added two new migrations and would like to run them without having to rollback my migrations table. But when doing so:
I get this error as artisan tryies to run de pauments migration again
You can migrate only a specific migration file :
php artisan migrate --path=/database/migrations/my_migration.php
Where my_migration will be your new migration file name like 2020_06_20_221554_create_additional_users_table
I created a MYSQL database using migrations, I added some data into it, but after that I recognized that I need to add a new column into my table.
I ran the command: 'php artisan migrate', but as it didn't work to synchronize
columns, it returns there is nothing to migrate.
So I ran the command 'php artisan migrate:reset', and then ran the command
'php artisan migrate' again, database schema updated correctly but for sure I
lost all my inserted data.
Now I'm just testing the application, but it would be very harmful if I found out that I should modify my database while it is runing with real data!!! What should I do in this case?
should I skip using migrations and create the Mysql database directly with
wamp? or use migration, but perform any later updates directly on database without updating the migration files? or there is another solution?
Answer
If you have already created a database table and realise you need to add more into it you can simply run: php artisan make:migration add_field_to_table_name --table=tableName
You then go into that file and create the new field. Once done simply run php artisan migrate and it'll add the new field into the desired table without causing any data loss.
Seeders
On another note, I would strongly suggest looking into seeders. This way when you're creating a project you can always refresh your migrations (wipe your database and re-migrate your tables) and then re-input the data using seeders.
you can create a migration to alter your tables. add new columns and more.
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.
I need to rollback a specific table as I forgot to mention foreign key.
and I dont want my data loss from all tables.
My framework is Laravel 5.4
Thanks in Advance Everyone
I do it this way:
Deleting a table manually;
Going to "migrations" table and deleting corresponding row to your migration;
php artisan migrate;
done
For example, if you modified migration called "Settings", then you delete this table from DB and migrations table, then rerun artisan command.
You can do
php artisan migrate:rollback --path=/database/migrations/your_file.php
Migrations are meant to be applied and rolled back in a specific order. Therefore there is no "proper" way of reapplying an arbitrary migration.
In any case there are at least two options:
"Fail forward" - create a subsequent migration that creates a necessary FK and apply it. This is the only proper way if you are already in production.
If you're just in early stages of development and don't won't to bloat the migrations directory you can
dump the tables so that you preserve the data
rollback up to this particular migration
fix and test the migration
migrate
load the data from dumps
Unfortunately there isn't an option to rollback a migration per table basis. You can only rollback the latest migration or last few migrations using the step parameter.
But there is a hacky way to do it in case you really need to. You can set the batch value in the migrations table to a higher number than the most recent migration for only the migrations you want to rollback. With this when you call php artisan migrate:rollback, only that particular migration files with batch value altered would rollback.