Updating columns with migration Laravel 5.4 - laravel-5

I have a running application, I see a field in a form is not required and can be left empty. but by the migrations, that field in database is set to be "not null". I wanted to to change it so I did it by checking Null. But how I do the same thing with migrations?? I read documentation and created this
public function up()
{
Scheme::table('modules', function (Blueprint $table) {
$table->text('content')->nullable();
});
}
but when I run migration, it give me error table already exists (obviously, because other migration files are there). How should I do it to achieve my target.

Change your code to this and notice the ->change() part:
public function up()
{
Scheme::table('modules', function (Blueprint $table) {
$table->text('content')->nullable()->change();
});
}
Documentation on changing columns
NB:
You'll need the Doctrine/DBal package in order for this to work:
Before modifying a column, be sure to add the doctrine/dbal dependency to your composer.json file. The Doctrine DBAL library is used to determine the current state of the column and create the SQL queries needed to make the specified adjustments to the column

Related

How to model a dependency graph in Laravel

I am stuck modelling the following relationship in a new application:
A Module can require (many) other Modules.
In Laravel I added the Module model and a ModuleRequirement model with its migrations. The second one has a foreign id field for the module it belongs to:
Schema::create('module_requirements', function (Blueprint $table) {
$table->id();
$table->foreignId('module_id')->constrained();
// How to reference other modules?
$table->integer('requires');
});
The relationship itself is defined by:
// Module.php
public function moduleRequirements()
{
return $this->hasMany(ModuleRequirement::class);
}
This method returns a collection of ModuleRequirements as expected. Unfortunately in order to get the real Module objects I need a foreach loop and build my own collection. I wonder if there is a simpler and faster solution. The perfect way I could imagine is sth. like $module->moduleRequirements returning a collection of the actual models instead of its ids.
My understanding that a module has relation with other modules in the same table.
you should use many to many relationship ,in that case you will not need a model for ModuleRequirement just a pivot table would be sufficient.
In your case module_requirements would act as the pivot table and you just need to change the relation in Module.php to :-
public function moduleRequirements(){
return $this->belongsTomany(Module::class,"module_requirements", 'module_id', 'requires');
}
the migration should be something like :-
Schema::create('module_requirements', function (Blueprint $table) {
$table->foreignId('module_id');
$table->foreignId('requires');
$table->foreign('module_id')->references('id')->on('models')->onDelete('cascade');
$table->foreign('requires')->references('id')->on('models')->onDelete('cascade');
});

Change the datatype in the column with data in laravel migration

This is the migration? i have to change the string data column into integer data column with existing data
public function up()
{
Schema::table('SYS_tenants' ,function (Blueprint $table){
$table->integer('tena_type')->unsigned()->nullable()->change();
$table->foreign('tena_type')->references('id')->on('account_types');
});
}
As per laravel Documentation you can create a new migration and do it like this:
Schema::table('SYS_tenants', function (Blueprint $table) {
$table->integer('tena_type')->unsigned()->nullable()->change();
});
Before modifying a column, be sure to add the doctrine/dbal dependency
to your composer.json file.
composer require doctrine/dbal
Reference: Laravel -> Database: Migrations-> Modifying Columns
You can use change method on the field which you want to change the type after setting the new field type.
public function up() {
Schema::table('SYS_tenants' ,function (Blueprint $table){
$table->string('tena_type')->change();
});
}
I supposed the migration which create the table has already call all requirement you need like unique, nullable and so on. You can call change method, by the way there isn't restriction about any modification you want to perform like add other mysql index on that field.
Do not forget to add doctrine/dbal in composer.json file
Migrations#Modifying Columns
Looks like what you have should work:
Schema::table('SYS_tenants' ,function (Blueprint $table){
$table->integer('tena_type')->unsigned()->nullable()->change();
});
Depending on your database you may need to cast the values to the new type: (for mysql: https://www.mysqltutorial.org/mysql-cast/)
I already use this Laravel Migration
$table->integer('tena_type')->unsigned()->nullable()->change();
But it doesn't work because, the data already in the table. In that case it can't change the datatype.I use this DB statement to change the datatype with data.it's working properly.
DB::statement("alter table SYS_tenants modify tena_type integer not null"):

Error with index when converting Laravel mysql migrations to postgresql

I have written about 10 Laravel migrations for a MySQL database. I want to now switch out my database for a Postgresql database but am having some trouble with indexes it seems.
I followed a tutorial about a voting module so I didnt write the migrations myself but they did all work when migrating on MySQL.
The error im getting is as follows;
SQLSTATE[42P07]: Duplicate table: 7 ERROR: relation "poll_id" already exists (SQL: create index "poll_id" on "gp_poll_votes" ("poll_id"))
There is no duplicate table and these migrations have been working for the last year or so.
The migration it is getting stuck on is as follows;
Schema::create('gp_poll_votes', function (Blueprint $table) {
$table->bigIncrements('id');
$table->bigInteger('poll_id')->unsigned();
$table->bigInteger('poll_option_id')->unsigned();
$table->bigInteger('vote_count');
$table->timestamps();
$table->index('poll_id', 'poll_id');
$table->index('poll_option_id', 'poll_option_id');
$table->foreign('poll_id')->references('id')->on('gp_polls')->onDelete('cascade');
$table->foreign('poll_option_id')->references('id')->on('gp_poll_options')->onDelete('cascade');
});
There is 2 more migrations associated with the votes which are run before the erroring one, which are;
Schema::create('gp_polls', function (Blueprint $table) {
$table->bigIncrements('id');
$table->tinyInteger('status')->nullable(false)->default(1);
$table->timestamps();
});
and
Schema::create('gp_poll_options', function (Blueprint $table) {
$table->bigIncrements('id');
$table->bigInteger('poll_id')->unsigned();
$table->bigInteger('image_id')->unsigned();
$table->tinyInteger('status')->nullable(false)->default(1);
$table->timestamps();
$table->index('poll_id', 'poll_id');
$table->index('image_id', 'image_id');
$table->foreign('image_id')->references('id')->on('gp_submit_images');
$table->foreign('poll_id')->references('id')->on('gp_polls')->onDelete('cascade');
});
In Postgres the index names have to be unique across the database it would seem, in MySQL that doesn't seem to matter.
You can create your indexes without passing a second argument, the name of the index, and Blueprint will create a more unique index name for you.
$table->index('poll_id'); // "gp_poll_options_poll_id_index"
It will use something like "{$prefix}{$table}_{$column}_{$typeOfIndex}" to generate the index name for you.

Populate table after running a migration

Background:
In my application, Users can own Files. It used to be that a File belongs to a single User, so I used a one-to-many relationship. Now, the requirements have changed, and my relationship needs to become many-to-many.
Previously, the data structure looked like this:
files
(
id,
user_id
...
);
and the new data structure looks like this:
files
(
id,
...
);
file_user
(
id,
file_id,
user_id,
);
Problem:
I created a migration to change my data structure, like this:
public function up()
{
Schema::create('file_user', function (Blueprint $table) {
$table->increments('id');
$table->timestamps();
$table->string('file_id', 36);
$table->string('user_id', 36);
});
}
Then, I set up the relationship in the corresponding models. Now i need to convert the old data into the new data structure. That means taking all the existing Files, and creating a new record in the file_user table. The code itself is simple:
foreach(File:all() as $file) {
$file->users()->attach($file->user_id);
}
I want to run this code alongside the migration, so that after running the migration, the table will populate. However, when I try to put it directly in the migration file like this:
public function up()
{
// create table
Schema::create('file_user', function (Blueprint $table) {
$table->increments('id');
$table->timestamps();
$table->string('file_id', 36);
$table->string('user_id', 36);
});
// convert old data
foreach(File:all() as $file) {
$file->users()->attach($file);
}
}
I get an exception:
PDOException: SQLSTATE[42P01]: Undefined table: 7 ERROR: relation "file_user" does not exist. It seems like the table has not been created yet at the time when the code is trying to run.
Question:
Is there a way that I can put the conversion code inside the migration file to make it work like expected? Or is there a better way to achieve this?
Try to create a second migration file, insert the // convert old data foreach(File::all() as $file) ... part there and migrate the two files together.

Laravel Database Migration Column altered to Unique and Nullable causing error

I am attempting to integrate social logins with my existing laravel app. I am attempting to change email and password to nullable but I also need email to remain unique. On executing my migration I am getting an error for duplicate key name 'users_email_unique'
Laravel 5, already fixed the issue with enum I had for altering a column.
Schema::table('users', function (Blueprint $table) {
$table->string('email')->unique()->nullable()->change();
$table->string('password')->nullable()->change();
});
Illuminate\Database\QueryException : SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'users_email_unique' (SQL: alter table users add unique users_email_unique(email))
Exception trace:
1 Doctrine\DBAL\Driver\PDOException::("SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'users_email_unique'")
/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:119
2 PDOException::("SQLSTATE[42000]: Syntax error or access violation: 1061 Duplicate key name 'users_email_unique'")
/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOStatement.php:117
Edit
If I remove Unique() from email, will it remain unique since that was previously set in a different migration?
You can change the uniqueness behaviour in a new migration by following below:
public function up()
{
Schema::table('contacts', function (Blueprint $table) {
$table->dropUnique(['email']);
});
}
/**
* Reverse the migrations.
*
*/
public function down()
{
Schema::table('contacts', function (Blueprint $table) {
$table->string('email')->unique()->change();
});
}
The Nullable() attribute will stay with the email column, since it was created with it.
It sound like the database is detecting a repeated value. That's impossible with nulls, so it could be an empty string maybe.
If that's the case, you can write a mutator function in your model to check if the value is empty and, set it to null before it goes to the database engine, like this:
public function setNameOfYourAttribute($value) {
if ( empty($value) ) {
$this->attributes['nameofyourattribute'] = NULL;
}
}
Hope it helps.
NOTE:
Full Documentation
Figured this out myself, as mentioned in the comment on the above answer.
Simply because the table was already created with unique() if I remove that it will allow the migration and will also persist the unique() functionality that was in the original User table migration.

Resources