I created a migration script that creates a table called Archives.
It has 4 columns not including timestamps/increments.
The tables columns are name, title, content and image.
I need to drop the image column as it is no longer needed.
I have not been able to find a way to do this by searching and was hoping someone could give me the best way to do this.
I attempted to accomplish this by creating a new migration and then running
php artisan migrate:rollback --pretend
But this tries to roll back the previous migration.
class DropImageColumnArchive extends Migration
{
/**
* Run the migrations.
* #return void
*/
public function up()
{
Schema::table('archives', function ($table) {
$table->text('image');
});
}
/**
* Reverse the migrations.
* #return void
*/
public function down()
{
Schema::table('archives', function ($table) {
$table->drop_column('image');
});
}
}
Almost there change drop_column to dropColumn
Referenced Here http://laravel.com/docs/schema#renaming-columns
Schema::table('users', function($table)
{
$table->dropColumn('votes');
});
Edit Referenced here for 5.1 http://laravel.com/docs/5.1/migrations
Related
I'm developing a web using Laravel 9. I used the command sail php make:migration add_bought_to_products_table to add a boolean column called "bought" in a products table. When trying to modify the value using Eloquent helpers (Product::where('id', $product->id)->update(array('bought'=>true)) the value is not updated in the database. When looking at it, I se that the new field "bought" created by the migration is marked as Read-only: No corresponding table column.
The migration code is the following:
<?php
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::table('products', function (Blueprint $table) {
$table->boolean('bought');
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::table('products', function (Blueprint $table) {
$table->dropColumn('bought');
});
}
};
Here a screenshot of the database:
I have already tried to clean the cache and rebuild many times the database doing a rollback and migrating again. The curious thing is that I previously added the field "visibility" which works perfectly with the exact same code and steps as the field that is giving the problem.
How can I solve it?
After breaking my head a lot, I solved it by simply doing a clean restart of the docker containers. It seems that the issue had nothing to do with Laravel but with Docker!
For anyone experiencing similar issues: make sure to end Docker and all containers and do a clean restart.
I simply restarted my database tool and it was gone.
In this code the table is created in the up method and deleted in the down() method. When I run the migration, the table is created but not deleted. In what way can I trigger the down method, so that I get a better understanding on how the two methods work?
<?php
use Illuminate\Support\Facades\Schema;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateFlightsTable extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('flights', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->string('airline');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('flights');
}
}
In your example:
php artisan migrate will run your up() method.
php artisan migrate:rollback will run your down() method.
Read up on the excellent docs: https://laravel.com/docs/5.7/migrations#migration-structure
You sohuld add dropIfExists instead of drop
and if you wanna just drop the specific migration file you should write your code in command like this:
php artisan migrate:rollback --path=\database\migrations\flights.php
Try:
public function down()
{
Schema::dropIfExists('flights');
}
Basically, up() is for creating tables or altering tables in the database, and down() is for reverting those changes.
Note: both of these methods create your own logic that how you want to go about making changes.
calling these methods:
up() php artisan migrate
down() php artisan migrate:rollback
I am using Laravel Stapler for image purposes and after migrating the new table, I attempt to artisan migrate:refresh afterwards and I am shown this error:
[Symfony\Component\Debug\Exception\FatalErrorException]
Class 'AddPhotoFieldsToStaffTable' not found
However, I can see the file within my migration's folder and using php artisan migrate, before trying to --refresh it, it successfully migrated!
The file that was generated is:
class AddPhotoFieldsToStaffTable extends Migration {
/**
* Make changes to the table.
*
* #return void
*/
public function up()
{
Schema::table('staff', function(Blueprint $table) {
$table->string('photo_file_name')->nullable();
$table->integer('photo_file_size')->nullable()->after('photo_file_name');
$table->string('photo_content_type')->nullable()->after('photo_file_size');
$table->timestamp('photo_updated_at')->nullable()->after('photo_content_type');
});
}
/**
* Revert the changes to the table.
*
* #return void
*/
public function down()
{
Schema::table('staff', function(Blueprint $table) {
$table->dropColumn('photo_file_name');
$table->dropColumn('photo_file_size');
$table->dropColumn('photo_content_type');
$table->dropColumn('photo_updated_at');
});
}
}
Any help would be greatly appreciated.
Using composer dumpautoload solved this issue.
Just do the command
composer dump-autoload
I'm new to using Laravel.
I have a .sql file where created a whole bunch of tables("CREATE TABLE my_table......."). Is there a way to somehow import these statements into Laravel? I could always manually rewrite these tables in raw php, but I feel that this would take too long and there is possibly an easier way to do it.
You would use migrations in Laravel to do this for example
I want to create a table called tasks I would use this command in artisan
php artisan make:model Task
This would create a model called task and a migration for this table.
You can then access the migration file and input something like this
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateTasksTable extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('tasks', function (Blueprint $table) {
$table->increments('task_id');
$table->string('name');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('tasks');
}
}
You would then run the artisan command to create this table
php artisan migrate
This then automatically creates your table.
Its a very useful feature and you can also rollback your migrations or even refesh it meaning it will remove the table and then reinstate it with no data in.
php artisan migrate:refresh
link to the docs
http://laravel.com/docs/5.1/migrations
This is a very basic question about laravel.
i have a migration file something like that
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class CreateDonorsTable extends Migration {
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('donors', function(Blueprint $table)
{
$table->increments('id');
$table->string('donor_name');
$table->string('email')->unique();
$table->string('blood_group');
$table->string('phone_number')->unique()->nullable();
$table->string('location');
$table->date('date_of_birth');
$table->date('last_date_of_donation');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('donors');
}
}
and i have already migrated my database using this migration file and uploaded it in a live server. now i have to update my migration file and have to add a new field namely donor_image.
how can i do this in a live server?what is the best possible way to update the migration file after uploading a larvel project in a live server?
The best practice is to make another migration file with just the changes (such as adding a column).
Then you run the new migration - which only makes the sub-set of changes listed.
Changing the original migration file is incorrect - and you now cannot use it to apply the changes (without destroying the original table).