A simple question for which I could not find the answer on google.
I have a Laravel 5.2 based project where some tables are no longer needed: is the correct way to create a migration with dropIfExists in it or should I just manually drop it and delete the migration responsible for the creation of the table?
On one hand, the migration gives me a rollback option, where I can recreate the table, but on the other hand, it is still stupid to create a table and then drop it again later. And the migration ( if suddenly needed ) can be always found in the repository.
You can just drop or delete yor migration file for the tables which are not in use, define php artisan make:model test --migration only when there is a need to create a migration file.
Or else if there is any need afterwards then create migration file for the same with php artisan make:migration.
You can do that or you can do a hack by modifying the value of batch Column in your migrations table
php artisan migrate:rollback command looks for the largest batch value in the migrations table and delete the corresponding table.
E.g: if you have 1,1,1,2,3,4,4 in your batch column and you run the rollback command it will delete all tables with the value 4.
Therefore, in your case increase all the batch value of your unwanted tables and run the rollback command.
Related
I recently imported new db to my local server and now when I created a new table and tried to migrate, it shows
SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '3' for key 'migrations.PRIMARY' (SQL: insert into migrations (migration, batch) values (2022_10_17_071124_create_team_histories_table, 11))
So, basically the system has started inserting the migration table id(pk) from 1 but right now my migration table has 39 rows(1-39 filled up). As a result when I run php artisan migrate it migrates the table but doesn't add the table record in the migrations table, thus any further migrations will fail with a error saying "the last_table_name already exists"
Now one way to solve this problem is to migrate the table then drop it and keep doing it until the system tries to insert 40 as the id of migration table.
So, I have have to migrate and drop my table 39 times to get there. This trick may work for very small db, but when it gets larger it's not really a solution rather it's another problem :v.
Any efficient solution will be a big help. Thanks!
Your scenario is not very clear.
Manage application base data
If your application need seeders for some table (ie populating a table that contains basic data), make seeders part of the migrations.
Data Import from another application
If you need to do a complete data import from another application, then do a complete database dump including migration table.
mysqldump --opt
With this option, mysqldump will include in your dump also the table creation and drop table statement
Then after data import, run migrations.
Migrations will run only if the codebase you are using has more recent migrations than the application from where you have dumped data
None of the above is an option
If this is not an option, maybe you can't do a dump again, you can try to fix the counter column by running
alter table migration AUTO_INCREMENT=39;
Of course adjust the 39 to your need
[I just want to update column in my existing entity class, but when I migrate to database using php bin/console ..., It's always shows table already exists or column could not be repeated ]
What should I do with this problem?
Make sure, what migration are you executing.
If you are not sure, you can delete all migrations in migrations folder
of your project.
And in your database, empty doctrine_migrations table.
Then, try to generate and execute migrations again.
You can execute the down action of the migration with:
bin/console doctrine:migration:execute --down "name_of_the_migration" .
Where the name of the migration is DoctrineMigrations\VersionXXXXXXXXXXXXXX. Then update what you need and migrate the migration again with the new changes.
i am working on laravel application. A small change in database table cause fresh migration. is there any method to re migrate only on table in laravel.
Just look at the migrations table in your database, there will be a list of migration file name and batch number value.
Suppose you have following structure,
id-------------------------migration---------------------------batch
1----------2014_10_12_000000_create_users_table---------------- 1
2----------2014_10_12_100000_create_password_resets_table-------1
3----------2016_09_07_103432_create_tabel_roles-----------------1
If you want to just rollback 2016_09_07_103432_create_tabel_roles migration, change it's migration batch value to 2 which is highest among all and then just execute following.
php artisan migrate:rollback
Here only table with batch value 2 will be rolled back. Now make changes to that table and run following console command.
php artisan migrate
Batch value in the migrations table defines order of the migrations. when you rollback, migrations that are latest or have highest batch value are rolled back at first and then others. So, you can change the value in database and then rollback a particular migration file.
Although it's not a good idea to change batch number every time because of relationship among the table structure, we can use this case for some cases where single table rollback doesn't violates the integrity among the tables.
Hope you understand.
You can use below command to re-migrate the all table.
Documents: https://laravel.com/docs/5.7/migrations
php artisan migrate:refresh
I created a new migration with php artisan make:migration --table=my_table and proceed to create a new column to an existing table. Said column is supposed to be a unique index, but I forgot to make it nullable, for that reason, php artisan migrate failed, as multiple rows would have a duplicate entry (which would be an empty string '')
Up to this point, the logical way to go is to add nullable to the column and re-run migrations. But since the new column already exist on the table (the migration failed when adding the unique key, but the column creation was successful) I have to drop it first.
My first thought was to run php artisan migrate:rollback but it executed a previous migration, not the one I just created.
Up to this point, what is the right way to do this? should I log into database cli and write query manually or laravel provide a way to handle this via php artisan?
I do think you can modify the original migration for your table and add the nullable, but you need to do this on the old migration. As you noticed, a new migration will just apply a patch to an existing table.
After modifying the migration you can rollback and forward again. Of course you need to be careful with your data (in case you need them check Database Seeding.
You can also use php artisan migrate:refresh this will delete all tables and data (so be really careful), but it should recreate your table with the new structure.
Try this:
php artisan migrate:rollback --table=table_name_here
app/migrations/create_user.php
public function up(){
Schema::create('interns', function($intern){
$intern->increments('id');
$intern->string('name');
$intern->integer('salary');
});
}
So the above function creates a table called "intern" but along with that it also creates a "migrations" table on running the command "php artisan migrate". Why is it doing this?
It's Laravel's way of keeping track of which migrations have been run.
Let's assume you make another table but it doesn't work right, so you need to run php artisan migrate:rollback. Laravel will know that the second table was created in the second batch and only rollback that one, leaving your interns table alone.
Every time you run another migration, that table will be updated with the migration's file name and the batch it was ran in.
The migrations table is for laravel to track the version the database is running.
For each migration it'll insert a new row into the migrations table, so that when you run migrate:rollback it knows what migrations to undo, and likewise, it knows what migrations to run going forward.
If you look at the migrations table you'll see it keeps a record of the migration name and batch number. The batch number is a sequential order that the migrations are run in. For example, you might create a users table. You run that and laravel logs the filename and batch number. Next you might add an accounts table that the users table is associated to. For this you would create 2 new migrations, one to create the new accounts table the other to edit the users table to add a new column account_id. Next time you migrate, both of the new migrations will be run, but assigned under the same batch id.