Related
using Laravel 7 and MySQL, I'm trying to add a foreign key to the Users table generated by the Laravel Auth system...
First, i've created my new table user_type and then, on another migration, I'm trying to add the foreign key to the users table, but then I get the error.
Here a gist with the migrations and the error: https://gist.github.com/jdalri/73cee7a00c513c93afd5186ca27d74a4
I've also tried using
$table->unsignedBigInteger('user_type_id');
$table->foreign('user_type_id')->references('id')->on('user_type');
but got the same error.
Thanks
your syntax is right but what is you missing is the foreign key doesnt have a default value(that exists in user_type table) or its not nullable. and its because there no record in user_type table with null value so if you reset the database with php artisan migrate:fresh that will work or make this column nullable.
$table->unsignedBigInteger('user_type_id')->nullable();
$table->foreign('user_type_id')->references('id')->on('user_type');
That works because literally the error is explaining that before you add content to the users table, user_type_id must have content. If you null it, it will work but its not a good idea to do so. I advise you if user_types are not much, create them as enum and choose the default one.
Here is a link to Laravel documentation: https://laravel.com/docs/7.x/migrations#foreign-key-constraints
Schema::table('users', function (Blueprint $table) {
$table->foreignId('user_type_id')->constrained('user_type');
});
There is no primary key for AddUserTypeToUsersTable
Try this
Schema::table('users', function (Blueprint $table) {
$table->increments('id');
$table->unsignedInteger('user_type_id');
$table->foreign('user_type_id')->references('id')->on('user_type');
});
I have an orders table and a have a sell_shipping_labels which references orders.id as a foreign. However when I run the Laravel migration I get the dreaded error code:
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1005 Can't create table cheapbooks_test.#sql-b5b_b2a (errno: 150 "Foreign key constraint is incorrectly formed") (SQL: alter table sell_shipping_labels add constraint sell_shipping_labels_order_id_foreign foreign key (order_id) references orders (id))
[Doctrine\DBAL\Driver\PDOException]
SQLSTATE[HY000]: General error: 1005 Can't create table cheapbooks_test.#sql-b5b_b2a (errno: 150 "Foreign key constraint is incorrectly formed")
This is my orders table schema:
Schema::create('orders', function (Blueprint $table) {
$table->increments('id');
$table->integer('user_id');
$table->integer('book_id');
$table->integer('status_id');
$table->double('payment_amount')->nullable();
$table->timestamp('received_at')->nullable();
$table->timestamp('paid_at')->nullable();
$table->timestamps();
$table->softDeletes();
});
And this is my sell_shipping_labels schema:
Schema::create('sell_shipping_labels', function (Blueprint $table) {
$table->increments('id');
$table->unsignedInteger('order_id');
$table->string('shippo_object_id');
$table->string('label_url');
$table->string('tracking_url');
$table->string('tracking_number');
$table->timestamp('arrived_at');
$table->timestamps();
$table->softDeletes();
$table->foreign('order_id')->references('id')->on('orders');
});
}
Now I've flipped the internet upside down trying to figure out the problem. All of the post about this problem all refer to the fact that the orders table must be created BEFORE the table that has the foreign key on it but this isn't a problem for me because my files are in the correct order.
Since increments() creates an unsigned integer column, you need to define the foreign key column as unsigned integer too.
Default migrations in Laravel 6+ use bigIncrements(), so you need to use unsignedBigInteger() method:
$table->unsignedBigInteger('order_id');
https://laravel.com/docs/6.x/migrations#foreign-key-constraints
For default migrations in older versions of Laravel use unsignedInteger() method:
$table->unsignedInteger('order_id');
Or:
$table->integer('order_id')->unsigned();
https://laravel.com/docs/5.5/migrations#foreign-key-constraints
the foreign key must be an "unsignedBigInteger" and it will be fixed,
something like this:
$table->unsignedBigInteger('user_id');
$table->foreign('user_id')->references('id')->on('users');
Primary key and foreign key should be in the same data type.
If the primary key is using unsigned big_integer, the foreign key should also be using unsigned big_integer.
In case laravel 5.8 uses bigIncrements by default when generating new migration (see this pull request), you should make sure that your foreign key is also unsigned big_integer or you will get error.
Table users:
Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name');
...
}
Table orders:
Schema::create('orders', function (Blueprint $table) {
$table->bigIncrements('id');
$table->unsignedBigInteger('user_id');
...
$table->foreign('user_id')->references('id')->on('users');
}
Hope this helps.
I was also getting the same error. What i was doing in users table is,
$table->unsignedInteger('role_id')->default(2);
table->foreign('role_id')->references('id')->on('roles')->onDelete('cascade');
But i have created the role table after creating users table. So, i edited the role migration file name date before the users table filename date. Like this,
2013_01_22_091213_create_roles_table.php
2014_10_12_000000_create_users_table.php
And finally it works. Maybe sometime you may get this problem. So, i posted it.
Laravel 5.8.3 comes with
$table->bigIncrements('id');
change it to
$table->increments('id');
$table->integer('order_id')->unsigned();
Most times the reason for this error is usually due to the order of which the migration files are listed or error due to type casting.
Always make sure that the migration of the file which the foreign constraints is to be imposed on comes after the parent migration.
And for the latter, make sure its an unsignedBigInteger , although former version of laravel (<5.4) could ignore this type casting error.
Migration files should be created in such a way that the parent migration should come first and the migration file with the foreign key next.
The foreign key and the primary id in the other table should have exactly similar property. If the primary id is increments then make the foreign key integer('xxx_id')->unsigned();
Check the order of your migrations. If your migrate command is trying to make the sell_shipping_labels table before the orders table this will occur with MySQL. It seems to go on create migration date, oldest to newest. In other words, the order_id on the table it is trying to reference should exist.
I have faced the same problem and I change create migration date.
To anyone looking at this using laravel 5.8.x
I fixed this by changing
this
$table->unsignedInteger('foreign_id');
to this
$table->unsignedBigInteger('foreign_id');
That's due to the use of bigIncrements.
You could instead remove chance bigIncrements to increments on both sides of the relation
For those which marked answer didn't work:
Check your table's engine. In my case, I was referencing a MyISAM table in an InnoDB source table. After changing the reference table engine to InnoDB, it worked!
Avoid all those two lines of codes with simple
which means sell_shipping_labels.order_id references id on orders table as below
Schema::table('sell_shipping_labels', function (Blueprint $table) {
$table->foreignId('order_id')->constrained('orders');
});
I had the same problem and fixed the issue setting the database type to innoDB
The tables created before the migration where 'MyISAM from an legacy system and the migrated are innoDB by default, so the mix of table types were an issue in my case.
I faced the same problem today. My laravel version is 5.8.29. I solved the problem by doing:
$table->bigIncrements('id'); //current table primary key and id
$table->unsignedBigInteger('user_id'); // foreigh key
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
Hope this works.
For laravel 6+ users, I agreed with the top 2 answers its all depends on laravel versions, For the latest versions users id column uses big integer. So referencing the users id from current migration you need to use unsignedBigInteger as a reference key.
Bellow is a migration example for laravel 6.5.*, Whenever we assign foreign key Keep in mind of your current laravel version
Schema::create('galleries', function (Blueprint $table) {
$table->bigIncrements('id');
==>$table->unsignedBigInteger('user_id');
$table->string('title');
$table->string('description');
$table->timestamps();
==>$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
});
I faced this problem today. I checked all of suggested solutions such as referenced key and foreign key same datatype, same collation in database engine and laravel config (database.php), date order of migrations and other possibility mistakes, but anyone were my solution!
last thing I found was onUpdate and onDelete constraints that put in migrations. By removing them my problem solved!
If the problem is still not solved, try it.
you need to create the last associated table.
You should first create orders and after create sell_shipping_labels table
To solve the issue you should rename migration files of Category and Users to date of before Meals Migration file that create those before Meals table.
[![enter image description here][1]][1]
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name');
$table->string('email')->unique();
$table->timestamp('email_verified_at')->nullable();
$table->string('password');
$table->rememberToken();
$table->timestamps();
});
}
I changed $table->bigIncrements('id') to $table->Increments('id')
For this user_id of files table become same integer type as user table field id. After this command worked.
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->string('email')->unique();
$table->timestamp('email_verified_at')->nullable();
$table->string('password');
$table->rememberToken();
$table->timestamps();
});
}
For the second table
{
Schema::create('files', function (Blueprint $table) {
$table->increments('id');
});
Schema::table('files', function($table) {
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
});
}
I faced this problem today. My parent table primary key datatype and child table data type was same but error was still there. I have found that my parent and child tables storage engine was different. I have fixed this issue by making both tables storage engine InnoDB from my phpmyadmin.
Better way to add foreign key in Laravel is using the alias. So instead of:
$table->unsignedBigInteger('user_id'); // foreigh key
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
We can simply do this:
$table->foreignId('user_id')->constrained();
And that works for me. Thanks!
my problem was solved when I used
bigInteger('user_id')->unsigned();
If your migration is depending on a parent migration, then you need to make sure your parent migration runs first. So what I did was:
Copy the content of the current child migration
Recreate the migration file using php artisan make:migration create_<models>_table
Run php artisan migrate:fresh
Hope that works.
I have two tables with a one-to-one relationship, set by a foreign key constraint. I want to set the onDelete rule to 'set default', meaning that when a row on the foreign table is dropped, the reference value reverts to its default value. Here is my code:
Tours Table:
Schema::create('tours', function (Blueprint $table) {
$table->increments('id')->unsigned()->index();
$table->integer('grade')->unsigned()->default(1);
$table->timestamps();
});
Grades Table:
Schema::create('grades', function(Blueprint $table){
$table->increments('id')->unsigned()->index();
$table->string('name');
$table->timestamps();
});
Set Foreign Key:
Schema::table('tours', function (Blueprint $table) {
$table->foreign('grade')->references('id')->on('grades')->onDelete('set default');
});
When I run my migrations, it works- no errors. However, looking at the table in HeidiSQL, it hasn't worked properly; the foreign key has been set, but the onDelete property just shows 'NO ACTION'.
Subsequently when I delete a row in the grades table, I get a foreign key constraint error.
What am I doing wrong?
It's been a while but.. it depends on the engine your database uses. If you use InnoDB or NDB, the syntax will be parsed but ignored.
Check this section of the MySQL documentation:
Referential Actions
...
SET DEFAULT: This action is recognized by the MySQL parser, but both InnoDB and NDB reject table definitions containing ON DELETE SET DEFAULT or ON UPDATE SET DEFAULT clauses.
You could use SET NULL instead in case this suit your needs. If not, then you could create an observer that'd perform this operation for you.
Here is the working solution.
First set the foreign key reference without any constraints.
Here is the code from the migration:
$table->foreignId('category_id');
Then set deleting model event on that model and update each related model:
Here I am updating category_id to 1 which is the default category and named as uncategorized and this can not be deleted.
Category::deleting(function ($category) {
$recipe_ids = $category->recipes->pluck('id');
Recipe::whereIn('id', $recipe_ids)->update(['category_id' => 1]);
});
I've just created a new Laravel 4 project and am finding strange things happening with the foreign key aspect of the schema builder. If I use the ->foreign() method in any of my migrations I get thrown MySQL errors 150 and general error 1005. According to the documentation at laravel.com/docs the two scenario's at the bottom should work? Anyone know why they don't?
The following does work:
Schema::create('areas', function($table)
{
$table->engine ='InnoDB';
$table->increments('id');
$table->integer('region_id')->references('id')->on('regions');
$table->string('name', 160);
$table->timestamps();
});
But these two do not work:
Schema::create('areas', function($table)
{
$table->engine ='InnoDB';
$table->increments('id');
$table->foreign('region_id')->references('id')->on('regions');
$table->string('name', 160);
$table->timestamps();
});
Schema::create('areas', function($table)
{
$table->engine ='InnoDB';
$table->increments('id');
$table->integer('region_id');
$table->foreign('region_id')->references('id')->on('regions');
$table->string('name', 160);
$table->timestamps();
});
Check your id type. Laravel 4 creates an incremental id with a int(10) unsigned.
If you create a basic integer and try to put a foreign key on it, it will fail.
As suggested in the documentation at this link, you should create the foreign id with $table->unsignedInteger(YOUR_ID_NAME); to make it work.
Also some answers over at this question "General error: 1005 Can't create table" Using Laravel Schema Build and Foreign Keys
A Summary of the answers listed there, including mine:
Foreign Keys generally require InnoDb, so set your default engine, or explicitly specify
$table->engine = 'InnoDB';
If your table is already created and has defaulted to MyISAM, you may need to alter it.
Foreign keys require the referenced table to exist. Make sure the referenced table is created in an earlier migration, prior to creating the key. Consider creating the keys in a separate migration to be sure.
Foreign Keys require the data type to be congruent. Check whether the referenced field is the same type, whether its signed or unsigned, whether it's length is the same (or less).
If you are switching between hand coding migrations, and using generators, make sure you check the id type you are using. Artisan uses increments() by default but Jeffrey Way appears to prefer integer('id', true).
Had same problem day ago.
Root of problem is : column with foreign key must be same type as that key.
And you have different types: INT/UNSIGNED INT
this makes id an UNSIGNED INT
$table->increments('id');
and this makes region_id an INT
$table->integer('region_id')->references('id')->on('regions');
To solve this, make region_id an UNSIGNED INT too
$table->integer('region_id')->unsigned()->references('id')->on('regions');
^^^^^^^^^ note here
Documentation of Laravel has mention about this :
Note: When creating a foreign key that references an incrementing integer, remember to always make the foreign key column unsigned.
It works, but sometimes you just have to be careful and try to understand what is happening behind the scene.
As I said in my comment. When you first ran the migration without creating the related column, Laravel migration services created your table and then, when you tried to migrate again it will always give you an error saying that the table already exists.
So you just have to drop table areas and run php artisan migrate again to fix it all.
EDIT:
I just created your migration (below) here and it worked.
As you can see I'm not using MySQL, so it must be a MySQL problem. Check MySQL foreign key documentation to see if your metadata fits in InnoDB requirements: http://dev.mysql.com/doc/refman/5.6/en/innodb-foreign-key-constraints.html.
<?php
use Illuminate\Database\Migrations\Migration;
class CreateAreasTable extends Migration {
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('regions', function($table)
{
// $table->engine = 'InnoDB';
$table->increments('id');
$table->string('name', 160)->unique();
$table->timestamps();
});
Schema::create('areas', function($table)
{
// $table->engine ='InnoDB';
$table->increments('id');
$table->integer('region_id');
$table->foreign('region_id')->references('id')->on('regions');
$table->string('name', 160);
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::drop('areas');
Schema::drop('regions');
}
}
antonio carlos is right, make sure that you created first the reference table of your foreign key.
try migrate first the tables without foreign keys , then make another migration assigning the foreign keys. on this state, laravel is sure that the reference key(s) are existing. and you dont have to drop tables during the artisan errors.
Essentially, I am having the same issue as this guy, minus the table prefix. Because I have no table prefix, his fix does not work. http://forums.laravel.com/viewtopic.php?id=972
I am trying to build a table using Laravel's Schema Builder like this:
Schema::create('lessons', function($table)
{
$table->increments('id');
$table->string('title')->nullable();
$table->string('summary')->nullable();
$table->timestamps();
});
Schema::create('tutorials', function($table)
{
$table->increments('id');
$table->integer('author');
$table->integer('lesson');
$table->string('title')->nullable();
$table->string('summary')->nullable();
$table->string('tagline')->nullable();
$table->text('content')->nullable();
$table->text('attachments')->nullable();
$table->timestamps();
});
Schema::table('tutorials', function($table)
{
$table->foreign('author')->references('id')->on('users');
$table->foreign('lesson')->references('id')->on('lessons');
});
The issue is, when I run this code (in a /setup route), I get the following error:
SQLSTATE[HY000]: General error: 1005 Can't create table 'tutorials.#sql-2cff_da' (errno: 150)
SQL: ALTER TABLE `tutorials` ADD CONSTRAINT tutorials_author_foreign FOREIGN KEY (`author`) REFERENCES `users` (`id`)
Bindings: array (
)
Based on posts around the web and the limited documentation available on how to setup Laravel's Eloquent relationships, I'm not sure what I'm doing wrong...
users already exists and it does have an id field that is auto_increment. I am also setting up my models with the proper relationships (belongs_to and has_many), but as far as I can tell this is not the issue-- it's the database setup. The DB is InnoDB.
What exactly am I doing wrong with the foreign key?
I've been having the same problem. I just noticed the following note at the very bottom of the Laravel Schema docs:
Note: The field referenced in the foreign key is very likely an auto increment and therefore automatically an unsigned integer. Please make sure to create the foreign key field with unsigned() as both fields have to be the exact same type, the engine on both tables has to be set to InnoDB, and the referenced table must be created before the table with the foreign key.
For me, as soon as I set my foreign key fields as such:
$table->integer('author')->unsigned();
I had no problem.
EDIT: Also, make sure that the fields in the foreign table are already created, otherwise this may fail with the same error.
I'm not 100% sure if these are the reasons this is failing but a couple of pointers. If you're using an older version of mySQL as the database, the default table implementation is myISAM that does not support foreign key restraints. As your scripts are failing on the foreign key assignment, you are better off explicitly stating that you want INNODB as the engine using this syntax in Schema's create method.
Schema::create('lessons', function($table)
{
$table->engine = 'InnoDB';
$table->increments('id');
$table->string('title')->nullable();
$table->string('summary')->nullable();
$table->timestamps();
});
This should hopefully alleviate the problems you are having.
Also, whilst you can declare foreign keys as an afterthought, I create the foreign keys within the initial schema as I can do an easy check to make sure I've got the right DB engine set.
Schema::create('tutorials', function($table)
{
$table->engine = 'InnoDB';
$table->increments('id');
$table->integer('author');
$table->integer('lesson');
$table->string('title')->nullable();
$table->string('summary')->nullable();
$table->string('tagline')->nullable();
$table->text('content')->nullable();
$table->text('attachments')->nullable();
$table->timestamps();
$table->foreign('author')->references('id')->on('users');
$table->foreign('lesson')->references('id')->on('lessons');
});
Hope this helps / solves your problem.
A Summary of the answers already listed, plus mine:
Foreign Keys generally require InnoDb, so set your default engine, or explicitly specify
$table->engine = 'InnoDB';
Foreign keys require the referenced table to exist. Make sure the referenced table is created in an earlier migration, prior to creating the key. Consider creating the keys in a separate migration to be sure.
Foreign Keys require the data type to be congruent. Check whether the referenced field is the same type, whether its signed or unsigned, whether it's length is the same (or less).
If you are switching between hand-coding migrations, and using generators, make sure you check the id type you are using. Artisan uses increments() by default but Jeffrey Way appears to prefer integer('id', true).
I ran into this issue too.
The solution I found is that the tables that contain the id that is being used a foreign id needs to be created before another table can reference it. Basically, you are creating a table and telling MySQL to reference another table's primary key but that table doesn't exist yet.
In your example, the author and lesson tables need to be created first.
The order in which the tables are created is dependent on artisan and the order you created your migration files.
My opinion would be to empty out your database of all the tables and change the timestamps in the migration file names (or delete them and recreate them in the correct order) so that your author and lesson tables are created before your tutorials table.
I received the same error because I forgot to set the table type to InnoDB on the referenced table:
$table->engine = 'InnoDB';
Laravel5, MySQL55, CentOS65
in my case the errors were same as this.
Error: [Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1005 Can't create table
'nabsh.#sql-5b0_e' (errno: 121) (SQL: alter table usermeta add
constraint usermeta_uid_foreign foreign key (uid) ref erences
users (id) on delete cascade).
I found a good tip in this problem's approved answer:
ERROR: Error 1005: Can't create table (errno: 121)
Tip: You will get this message if you're trying to add a constraint with a name that's already used somewhere else.
in my case this error means the constraint which has been tried to add is already exists somewhere (but i couldn't see them anywhere).
I copied the output error query and execute it within sequel pro, then hopefully I saw the same error again. as the tip says I changed the constraint name to something else then it affected with no error so there's a problem with constraint name builder in laravel5 + MySQL55 + CentOS65.
Solution: try to rename constraints by sending the second parameter at foreign method in table schema.
Schema::table('tutorials', function($table)
{
$table->foreign('author')->references('id')->on('users');
$table->foreign('lesson')->references('id')->on('lessons');
});
to ->
Schema::table('tutorials', function($table)
{
$table->foreign('author', 'fk_tutorials_author')->references('id')->on('users');
$table->foreign('lesson', 'fk_tutorials_lesson')->references('id')->on('lessons');
});
i hope it helps. it works in my case
Easiest way is to disable foreign key checks:
DB::statement('set foreign_key_checks=0');
Schema::table( ... );
DB::statement('set foreign_key_checks=1');
This happened to me in Yii Framework 1.x migrations too. Turned out that
similarily to the Laravel solutions above it may be caused by a
wrong spelled (or not yet existing) table name
wrong spelled (or not yet existing) column name
duplicate foreign key name in the same database being used in different tables
when using foreign key-s make sure that your foreign key is unsigned. this worked for me
Here's what I do in Laravel 5:
// CREATING TABLE
Schema::create('your_table_name', function (Blueprint $table) {
$table->engine = 'InnoDB';
$table->increments('id'); // index field example sample
$table->string('field2'); // some varchar/string field sample
$table->integer('field3'); // some integer field sample
$table->integer('field_some_table_id')->unsigned; //for field that contains foreign key constraint
});
// FOREIGN KEY CONSTRAINT
Schema::table('stock', function ($table) {
$table->foreign('field_some_table_id')->references('id')->on('some_table')->onDelete('cascade')->onUpdate('cascade');
});
That's all for the conclusion, and it works for me.
You have to give the integer an unsigned flag in Laravel 5.4, like this:
public function up()
{
Schema::create('posts', function (Blueprint $table) {
$table->increments('post_id');
$table->text('title');
$table->text('text');
$table->integer('employee_post_id_number')->unsigned();
$table->foreign('employee_post_id_number')->references
('employee_id_number')->on('employees');
$table->timestamps();
});
}
Basically, you get this error because the migration command creates tables in an order which does not match the FK reference you are providing for tables.
Like if you want to create an FK which should refer to the id in users table then users table must exist.
In your example, the author and lesson tables need to be created first.
So, I solved this by creating the tables (one by one) in such order, where I can successfully refer the FK to an existing table. So that Php Artisan Migration cannot decide the order.
Another solution is, you can simply rename the tables or the timestamps provided by migration command .
By using:
$table->unsignedInteger('author');
instead of:
$table->integer('author');
the problem will be solved.
The problem is that integer generates an int(11) variable while you need an int(10) variable. unsignedInteger will make it for you.
One of the reasons for this error can be the time and date creation of the migration files. For example , if we have tasks which belongs to some tasks groups, and there is references like:
"create_tasks_table
$table->id();
$table->string('task_name');
$table->integer('task_group')->unsigned();
$table->foreign('task_group')
->references('id')->on('tasks_groups')->onDelete('cascade');
$table->longText('task_desc');...."
it is important to create migration file for tasks_groups first (in the name of file we can see the time and date of creation) and than we should create tasks which belongs to some tasks_groups
also it is better to form the migration files with relations like this:
enter codeOne of the reasons for this error can be the time and date creation of the migration files. For example , if we have tasks which belongs to some tasks groups, and there is references like:
"create_tasks_table
$table->id();
$table->string('task_name');
$table->integer('task_group')->unsigned();
$table->foreign('task_group')
->references('id')->on('tasks_groups')->onDelete('cascade');
$table->longText('task_desc');...."
it is important to create migration file for tasks_groups first (in the name of file we can see the time and date of creation) and than we should create tasks which belongs to some tasks_groups
also
migration table should look like this
`use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
class CreateTasksTable extends Migration
{
/**
* Run the migrations.
*
* #return void
*/
public function up()
{
Schema::create('tasks_groups', function (Blueprint $table) {
$table->increments('id');
$table->string('group_name');
$table->string('slug');
$table->timestamps();
});
Schema::create('tasks', function (Blueprint $table) {
$table->id();
$table->string('task_name');
$table->integer('task_group')->unsigned();
$table->foreign('task_group')
->references('id')->on('tasks_groups')->onDelete('cascade');
$table->longText('task_desc');
$table->string('izvrsioc');
$table->string('ulogovani_rukovodioc');
$table->date('time_finishingtask');
$table->string('prioritet_izrade')->default('');
$table->string('file_1')->nullable();
$table->string('file_path1')->nullable();
$table->string('file_2')->nullable();
$table->string('file_path2')->nullable();
$table->string('file_3')->nullable();
$table->string('file_path3')->nullable();
$table->longText('dodatni_komentar');
$table->boolean('zavrsen_task')->default(false);
$table->boolean('otkazan_task')->default(false);
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* #return void
*/
public function down()
{
Schema::dropIfExists('tasks');
Schema::dropIfExists('tasks_groups');
}
}`
it is better if there is relation
I was facing this problem, I just solved it this way
Add ->unsigned() with any column you add to represent a relationship
example:
errorr
$table->integer('lesson');
right is
$table->integer('lesson')->unsigned();