Trying to setup a migration that will make my already existing "active" field have a default value of "1".
I see in the docs I can use something like:
$table->integer('active')->default(1);
But I tried this in my migration with no success, I guess because the field already exists. Is there a way to correctly manage existing fields using the schema builder?
My current migration:
public function up()
{
Schema::table('scores', function($table){
$table->integer('active')->default(1);
});
}
Edit:
From what I've read so far, this can't be done with the query builder. But when I try to run a raw query:
DB::query("ALTER TABLE `scores` CHANGE COLUMN `active` `active` int(11) NOT NULL DEFAULT '1';");
I'm getting a "method 'query' does not exist error", so I'm guessing this method name was changed I just can't find what it was changed to
Looks like DB::query() was changed to DB::statement()
This did the trick:
DB::statement("ALTER TABLE `scores` CHANGE COLUMN `active` `active` int(11) NOT NULL DEFAULT '1';");
Related
I'm using Laravel 7.
I want to update a JSON column using Laravel's Eloquent. The problem is that if the value of the column is null the column won't be updated.
This is how the code looks like:
Model::update(['jsonColumnName->jsonColumnKey' => 'value']);
This is the SQL that it would generate:
UPDATE model
SET jsonColumnName = JSON_SET(jsonColumnName, '$.jsonColumnKey', 'value');
According to the documentation of JSON_SET, it will take the first parameter as the JSON document that it will modify. In this case, that value would be null since jsonColumnName is currently null. Because of that it returns null since it has nothing to modify and it ends doing nothing.
If I manually set the value of the column to {} and run the showed code, it works. But I guess that you are not expected to do that (right?).
You should make new alter table migration and change json column to have default value {}.
First you need to check if there is already installed dbal with
composer require doctrine/dbal
Then make new migration with code in up() method:
Schema::table('table_name', function (Blueprint $table) {
$table->json('column_name')->nullable()->default(null)->change();
});
Don't forget to backup database before work on it.
With NULL value you can also check if that field is empty.
Another way, on framework level is to set logic about this issue into model's observer.
For example:
public function saving(EntityModel $entityModel)
{
if (is_null($entityModel->json_column)) {
$entityModel->json_column = '{}';
}
}
I don't understand this, I alter my table to add these columns
Schema::table('clusters', function($table)
{
$table->string('ssaEnabled',1)->default('0');
$table->string('ssaBackendUrl')->default(NULL);
$table->string('ssaPortalApiUrl')->default(NULL);
});
in my store() I have this
$cluster->ssaEnabled = Input::get('ssaEnabled','0');
$cluster->ssaBackendUrl = Input::get('ssaBackendUrl','');
$cluster->ssaPortalApiUrl = Input::get('ssaPortalApiUrl','');
$cluster->save();
I kept getting
prod.ERROR: SQLSTATE[23502]: Not null violation: 7 ERROR: null value in column "ssaBackendUrl" violates not-null constraint
Why ??
I set it to default null already
I also add a backup value in my Input::get() in the 2nd param as an empty string
Any hints?
How can I stop that ?
Create a new migration
php artisan make:migration add_nullable_to_ssaBackendUrl_column_on_clusters_table --table=clusters
Updating Column Attributes
The change method allows you to modify the type and attributes of
existing columns.
Schema::table('clusters', function($table)
{
$table->string('ssaBackendUrl')->nullable()->change();
});
Run the migration
php artisan migrate
I'm having an issue with attempting to run tests in my Laravel application. I have a table structure as follows:
These SQL Queries have been generated by an export script using TablePlus, as I figured it was the easiest way to share the table structure.
After Migration (NOW)
CREATE TABLE `business_system_role_location_type` (
`business_system_role_id` char(36) COLLATE utf8mb4_unicode_ci NOT NULL,
`location_type_id` char(36) COLLATE utf8mb4_unicode_ci NOT NULL,
PRIMARY KEY (`business_system_role_id`,`location_type_id`),
KEY `business_system_role_loc_type_fk` (`location_type_id`),
CONSTRAINT `business_system_role_loc_type_fk` FOREIGN KEY (`location_type_id`) REFERENCES `location_types` (`id`),
CONSTRAINT `business_system_role_loc_type_role_id_fk` FOREIGN KEY (`business_system_role_id`) REFERENCES `business_system_roles` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Before Migration
CREATE TABLE `business_system_role_location_type` (
`business_system_role_id` char(36) COLLATE utf8mb4_unicode_ci NOT NULL,
`location_type` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL,
PRIMARY KEY (`business_system_role_id`,`location_type`),
CONSTRAINT `business_system_role_loc_type_role_id_fk` FOREIGN KEY (`business_system_role_id`) REFERENCES `business_system_roles` (`id`) ON DELETE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
So as you can see, I have ran a migration and removed the location_type field and replaced it with a foreign key to a new location_types table. Both the business_system_role_id and location_type are set to UNIQUE PRIMARY KEY.
This all appears to work fine with MySQL but as soon as I attempt to run any of my tests (using SQLite) it stops working and complains:
Illuminate\Database\QueryException : SQLSTATE[23000]: Integrity constraint violation: 19 NOT NULL constraint failed: business_system_role_location_type.location_type (SQL: insert into "business_system_role_location_type" ("business_system_role_id", "location_type_id") values (bb2051c2-1b5c-498d-bbcf-6dd9e20c4803, 38215722-bcba-4cac-8c83-fe867d8d8e65))
Question
Why am i getting a NOT NULL constraint for business_system_role_location_type.location_type when that column no longer exists? I have tried setting location_type to nullable->(true) before the migration, on the assumption it might update some SQLite setting, but this did not work.
I tried adjusting my code so that it performed $model->location_type = 'something' before $model->save(), and that worked... Even though the column does not exist. All references to it have been removed. I don't want to have to live with a workaround here and would like to get to the bottom of the reason for this error.
The Model looks as follows:
class BusinessSystemRoleLocationType extends Model
{
protected $table = 'business_system_role_location_type';
protected $fillable = [
'business_system_role_id',
'location_type_id',
];
public $incrementing = false;
public $timestamps = false;
public function businessSystemRole(): BelongsTo
{
return $this->belongsTo(
BusinessSystemRole::class,
'business_system_role_id',
'id'
);
}
}
Any help here would be greatly appreciated. :)
Edit - Migration
Here is the portion of the migration which deals with this table:
// Add location_type_id field to table
Schema::table('business_system_role_location_type', function (Blueprint $table) {
// Must be nullable until it is populated with data
$table->uuid('location_type_id')
->nullable()
->after('business_system_role_id');
});
// Assign location_type_id value to all entries
BusinessSystemRoleLocationType::all()->each(function ($businessSystemRoleLocationType) {
$locationTypeDataSetIndex = \array_search(
$businessSystemRoleLocationType->location_type,
\array_column($this->locationTypeDataSet, 'existsAs'),
true
);
if ($locationTypeDataSetIndex !== false) {
$newLocationTypeData = $this->locationTypeDataSet[$locationTypeDataSetIndex];
$newLocationType = LocationType::whereSlug($newLocationTypeData['slug'])->get()->first();
} else {
$newLocationType = LocationType::all()->first();
}
$businessSystemRoleLocationType->location_type_id = $newLocationType->id;
$businessSystemRoleLocationType->save();
});
// Adjust primary index and add foreign keys, and drop location_type field from table
Schema::table('business_system_role_location_type', function (Blueprint $table) {
$table->dropForeign('business_system_role_loc_type_role_id_fk');
$table->dropPrimary(['business_system_role_id', 'location_type']);
});
Schema::table('business_system_role_location_type', function (Blueprint $table) {
// ATTEMPT TO SET FIELD TO NULLABLE BEFORE REMOVING IT, MAYBE THIS WILL FIX THE NOT NULL CONSTRAINT ERROR?
$table->string('location_type')->nullable()->change();
});
Schema::table('business_system_role_location_type', function (Blueprint $table) {
$table->foreign('location_type_id', 'business_system_role_loc_type_fk')
->references('id')
->on('location_types');
$table->foreign('business_system_role_id', 'business_system_role_loc_type_role_id_fk')
->references('id')
->on('business_system_roles')
->onDelete('cascade');
// Now set not nullable UUID (Doctrine (change()) does not support UUID type)
$table->string('location_type_id', 36)->change();
$table->primary(['business_system_role_id', 'location_type_id'], 'business_system_role_loc_type_pk');
$table->dropColumn('location_type');
});
Edit 2 - Solution
I am editing here to provide my solution - though I will leave this open as others will most likely provide a better answer.
From what I can understand in order to remove constraints in an SQLite database it is recommended to delete the table and recreate it. (See here: https://stackoverflow.com/a/4007086/9675332). It appears that SQLite saves these constraints somewhere and doesn't actually remove them just because you remove the column. I really did not want to go down this route though, so here is what i did:
Solution 1: I modified my migration to set the field to have a default value before removing it, and this did pass the test (though it then subsequently failed on the UNIQUE constraint so it's not a working solution in my case, but may well work for others!)
Solution 2: Probably what I should have done to begin with actually. I simply renamed the column from location_type to location_type_id and manually set it to char(36). This appears to have updated everything in the background along with it and it now passes the tests.
I am using Laravel 5.1 and I have a table called packages with this structure:
id int(11)
weight decimal(10,2)
weight_unit enum('Kg.', 'Gm.')
I would like to change the weight_unit enum to:
weight_unit enum('Grams','Kgs.','Pounds')
For this I create the following migration:
public function up()
{
Schema::table('packages', function ($table) {
$table->enum('weight_unit', array('Grams','Kgs.','Pounds'))->nullable()->change();
});
}
But when I run the migration I receive an error:
Unknown database type enum requested, Doctrine\DBAL\Platforms\MySqlPlatform
may not support it.
How can I change this enum?
Use the DB::statement method:
DB::statement("ALTER TABLE packages MODIFY COLUMN weight_unit ENUM('Grams', 'Kgs', 'Pounds')");
This worked for me when adding a new enum value to the modified enum column.
Add the following to the up() method:
DB::statement("ALTER TABLE packages MODIFY weight_unit ENUM('Grams', 'Kgs', 'Pounds', 'new value') NOT NULL");
Then in the down() method you can revert the change that was made:
DB::statement("ALTER TABLE packages MODIFY weight_unit ENUM('Grams', 'Kgs', 'Pounds') NOT NULL");
Note: before the enum value is removed it needs to be changed to another enum value that will be retained.
$table->enum('level', ['easy', 'hard']);
You can add custom constructor to migration and explain to Doctrine that enum should be treated like string.
public function __construct(\Doctrine\DBAL\Migrations\Version $version)
{
parent::__construct($version);
$this->platform->registerDoctrineTypeMapping('enum', 'string');
}
In case you dont want to lose your data and update it with the new values I came up with this solution:
// Include old and new enum values
DB::statement("ALTER TABLE packages MODIFY COLUMN weight_unit ENUM('Kg.', 'Gm.', 'Grams', 'Kgs', 'Pounds')");
// Replace Kg. with Kgs
Packages::where('weight_unit', 'Kg.')->update(['weight_unit' => 'Kgs']);
// Replace Gm. with Grams
Packages::where('weight_unit', 'Gm.')->update(['weight_unit' => 'Grams']);
// Delete old values
DB::statement("ALTER TABLE packages MODIFY COLUMN weight_unit ENUM('Grams', 'Kgs', 'Pounds')");
This way you can replace your old values with the new ones.
add this before change() call :
DB::getDoctrineSchemaManager()->getDatabasePlatform()->registerDoctrineTypeMapping('enum', 'string');
I think that is fixed on Laravel 10 by adding support for native column modifying.
https://github.com/laravel/framework/pull/45487
So from Laravel 10 you can do this:
Schema::table('jobs', function (Blueprint $table) {
$table->enum('type', ['contract', 'permanent', 'partial'])->change();
});
I tried the same migration on fresh Laravel 9.55.0 and 10.0.2 application:
laravel-9.52.0.jpg
laravel-10.0.2.jpg
I am able to solve this by removing and adding constraints. This has made sure that my existing data is also is intact.
DB::statement("ALTER TABLE purchases DROP CONSTRAINT purchases_ref_check");
$types = ['single', 'monthly', 'biannual', 'amount', 'other'];
$result = join( ', ', array_map(function( $value ){ return sprintf("'%s'::character varying", $value); }, $types) );
DB::statement("ALTER TABLE purchases add CONSTRAINT purchases_ref_check CHECK (ref::text = ANY (ARRAY[$result]::text[]))");
with default value. add this in up():
\DB::statement("ALTER TABLE `patient_appointments` CHANGE `status` `status` ENUM('pending','wait','approved', 'consulted') CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'pending';");
I am adding a field to a table in a migration that I wish to allow to be NULL but also I wish for it to default to NULL. What do I place in the default method? I fear that putting "NULL" in will attempt to place a string of NULLin which I obviously don't want. Please help :)
Schema::table('item_categories', function(Blueprint $table)
{
$table->integer('parent_item_category_id')->unsigned()->nullable()->default($what_to_put here);
});
When you use the nullable() method on a field, that field will default to NULL.
$table->integer('parent_item_category_id')->nullable();
To make the column "nullable", you may use the nullable method:
$table->string('email')->nullable();