[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.
Related
I had some record in table inserted by SomeTableSeeder, I have deleted records from table and updated the SomeTableSeeder (added one more record). When I am running the php artisan db:seed --class=SomeTableSeeder, the new record I added later is not getting inserted in the database. Old record is getting inserted only. Any idea why?
Note: I am using remote database host. If that's the reason then new migrations should also not run. New migrations are running only newly added record in old table seeder is not inserting any record.
I have tried creating new seeder, I am getting error
Illuminate\Contracts\Container\BindingResolutionException : Target class [NewTableSeeder] does not exist.
If you are sure that your DB is connecting correctly, don't forget to instruct the general seeder - DatabaseSeeder.php in <<your_project>>/database/seeders/DatabaseSeeder.php to seed the database. Your tables should be listed in the run method: \App\Models\User::factory(20)->create();
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
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.
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.