What am I doing wrong?
option-migration file
Schema::create('option', function (Blueprint $table) {
$table->increments('id');
$table->integer('contents_content_id')->unsigned();
$table->timestamps();
$table->foreign('contents_content_id')
->references('content_id')
->on('contents');
});
contents-migration-file
Schema::create('contents', function (Blueprint $table) {
$table->increments('id');
$table->integer('content_id');
$table->timestamps();
});
error
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint (SQL: alter table option add constraint option_content_content_id_foreign foreign key (content_content_id) references contents (content_id))
[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint
The problem is that the option table get created before the contents table, and when you reference content_id on content, content table doesn't exist yet.
Note that :
Each migration file name contains a timestamp which allows Laravel to determine the order of the migrations.
So what you have to do now, is to delete the migrations from database/migrations folder and re-create them in order : first options then contents.
Related
I have this error when run migration
SQLSTATE[HY000]: General error: 1005 Can't create table tms-app.#sql-1e64_2b (errno: 150 "Foreign key constraint is incorrectly formed") (SQL: alter table projects add constraint projects_cout_id_foreign foreign key (cout_id) references couts (id) on update cascade)
this is projects table:
Schema::create('projects', function (Blueprint $table) {
$table->increments('id');
$table->string('libelle');
$table->string('libelle_long');
$table->string('direction');
$table->integer('cout_id')->unsigned();
$table->foreign('cout_id')
->references('id')->on('couts')
->onUpdate('cascade');
$table->foreign('status')
->referenecs('id')->on('statuses')
->onUpdate('cascade')
->onDelete('cascade');
$table->timestamps();
});
Sometimes this error happens, when we define foreign key and you should use bigInteger('') or use unsignedBigInteger('').
Use the code below:
Schema::create('projects', function (Blueprint $table) {
$table->increments('id');
$table->string('libelle');
$table->string('libelle_long');
$table->string('direction');
$table->bigInteger('cout_id')->unsigned();
$table->bigInteger('status')->unsigned();
$table->foreign('cout_id')->references('id')->on('couts')->onDelete('cascade');
$table->foreign('status')->references('id')->on('statuses')->onDelete('cascade');
$table->timestamps();
});
Note: In tables couts & statuses change the id field $table->increments('id'); to $table->bigIncrements('id');
This error should be casuses by the following miss-configuration below I mentioned, be sure all of them to be configured correctly
1: Laravel migration foriegn key should be assgined as bigInteger or unsignedBigInteger
example:
$table->unsignedBigInteger('user_id');
or
$table->bigInteger('user_id')->unsigned();
and for assigning foriegn key attribute you should do
$table->foriegn('user_id')->reference('id')->on('users'); // if you need further attribtute you can chain to this line
2: be sure that the order of migration file is formed correclty because Laravel will migrate table based on timestamp for example if need a foreign key from user table first you need to create user table then the child table the timestamp of users table should be older than child (even 1 second)
I have these two migration files one to create a faq_channels table and another to create a faq_questions table. However, I'm not understanding why it is showing an error:
SQLSTATE[HY000]: General error: 1005 Can't create table `test`.`faq_questions` (errno: 150 "Foreign key constraint is incorrectly formed") (SQL: alter table `faq_questions` add const
raint `faq_questions_channel_id_foreign` foreign key (`channel_id`) references `faq_channels` (`id`) on delete cascade)
Do you know why?
// create_faq_channels_table
public function up()
{
Schema::create('faq_channels', function (Blueprint $table) {
$table->id();
$table->string('channel');
$table->text('description');
$table->timestamps();
});
}
// create_faq_questions_table
Schema::create('faq_questions', function (Blueprint $table) {
$table->id();
$table->unsignedBigInteger('channel_id');
$table->string('question');
$table->text('response');
$table->timestamps();
$table->foreign('channel_id')->references('id')->on('faq_channels')->onDelete('cascade');
});
I have these two migration files one to create a faq_channels table
and another to create a faq_questions table.
Make sure that migration file for 'faq_channels' table runs before the migration file for 'faq_questions' table. Generally this type of error rises when the parent table is not created before declaring foreign key constraint.
Also edit your migration files according to Talha F.'s answer.
After trying all of this possibility, still, have this error message:
SQLSTATE[HY000]: General error: 1824 Failed to open the referenced table 'categories'
(SQL: alter table `users` add constraint `users_category_id_foreign` foreign key
(`category_id`) references `categories` (`id`) on delete cascade)
The code of relation in users migration:
$table->unsignedBigInteger('category_id');
$table->foreign('category_id')->references('id')->on('categories')->onDelete('cascade');
The image of the table:
Help :(
Remove those lines from the create_users_table migration and add this to the create_categories_table.
// function up() below the Schema::create('categories'..
Schema::table('users', function (Blueprint $table) {
$table->unsignedBigInteger('category_id')->nullable();
$table->foreign('category_id')->references('id')->on('categories')->onDelete('cascade');
});
I made it nullable because again, you are adding it to an existing table, so if you happen to have any users in the table, the migration will fail again if there is no default value.
why laravel schema reply
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1005 Can't create table test.#sql-13cc_d0 (errno: 150 "Foreign key constraint is incorrectly formed") (SQL: alter table cities add constrai
nt cities_provinces_id_foreign foreign key (provinces_id) references provinces (id) on delete cascade)
[PDOException] SQLSTATE[HY000]: General error: 1005 Can't create
table test.#sql-13cc_d0 (errno: 150 "Foreign key constraint is
incorrectly formed")
first table
Schema::create('provinces', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->boolean('is_enable');
$table->boolean('is_deletable');
$table->boolean('is_editable');
$table->boolean('deleted');
$table->timestamps();
});
second table
Schema::create('cities', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->integer('province_id')->unsigned()->index();
$table->boolean('is_enable');
$table->boolean('is_deletable');
$table->boolean('is_editable');
$table->boolean('deleted');
$table->timestamps();
$table->foreign('province_id')
->references('id')->on('provinces')
->onDelete('cascade');
});
You should make sure, your provinces table migration is running before cities table migration.
You should change provinces or cities migration file name to make sure timestamp at the beginning of provinces table migration file will be before cities table.
The time go ahead but i will comment something else.
Andile is right! You must have the same type. In this case, the foreign key should have the type bigInteger because you have bigIncrements on the reference table.
I think thats the solution for a little and boring debug. (sorry for my english)
Try to create table first and then add constraint:
Schema::create('cities', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->integer('province_id')->unsigned()->index();
$table->boolean('is_enable');
$table->boolean('is_deletable');
$table->boolean('is_editable');
$table->boolean('deleted');
$table->timestamps();
});
Schema::table('cities', function (Blueprint $table) {
$table->foreign('province_id')->references('id')->on('provinces')->onDelete('cascade');
});
The foreign key and referencing table must be same type, the auto generated id are of bigInteger, so instead of defining your column as Integer use bigInteger insteated. That Solved the problem for me
I am trying to reference the id of a product on two tables (a categories and a brands table).
public function up()
{
Schema::create('products', function($table)
{
$table->increments('id');
$table->integer('category_id')->unsigned();
$table->integer('brand_id')->unsigned();
$table->string('title');
$table->text('description');
$table->decimal('price', 6, 2);
$table->boolean('availability')->default(1);
$table->string('image');
$table->timestamps();
});
Schema::table('products', function($table){
$table->foreign('category_id')->references('id')->on('categories');
$table->foreign('brand_id')->references('id')->on('brands');
});
}
But I get the following errors:
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint (SQL
: alter table `products` add constraint products_brand_id_foreign foreign k
ey (`brand_id`) references `brands` (`id`))
[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint
Which is the correct way to do this?
Update
Migration public function up for the brands table
public function up()
{
Schema::create('brands', function($table){
$table->increments('id');
$table->string('name');
$table->timestamps();
});
}
Solution
Finally, the error was on the naming of the migration. Due to the fact that brands table was the most recent table I had to changed its name from: 2014_12_12_164325_create_brands_table to this 2014_10_12_164325_create_brands_table and the tables were migrated successfully.
Everything looks ok to me. Furthermore, since it only complains about the second part, the categories foreign key must've worked. I would think the brands table doesn't exist or there is something wrong there. Does the table exist and does it have a primary key "id"?
I also use
$table->engine = 'InnoDB';
at the beginning, because MyISAM doesn't support foreign keys as of now. I don't think it should be an issue in the above case, but perhaps still advisable, if you want to do foreign key restrictions on the DB level.