I am trying to go through the tagging video in L5 and when I try to migrate I get this error:
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint (SQL
: alter table article_tags add constraint article_tags_article_id_foreign
foreign key (article_id) references articles (id) on delete cascade)
[PDOException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint
public function up()
{
Schema::create('tags', function(Blueprint $table)
{
$table->increments('id');
$table->string('name');
$table->timestamps();
});
Schema::create('article_tags', function(Blueprint $table)
{
$table->integer('article_id')->unasigned()->index();
$table->integer('tag_id')->unasigned()->index();
$table->timestamps();
});
Schema::table('article_tags', function(Blueprint $table)
{
$table->foreign('article_id')->references('id')->on('articles')->onDelete('cascade');
$table->foreign('tag_id')->references('id')->on('tags')->onDelete('cascade');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('tags');
Schema::drop('article_tag');
}
}
I tried to separate the the migration into two parts thinking that would solve this issue.
What did I do wrong?
Yes you have to make right order and you should just Refactor > Rename and rename file (change date or trailing number) to push some file up/down migration sorts files by name.
I think I figured it out. In Sql Pro For the ID's I unchecked Unsigned. I was then able to run this from the Sequel Pro Gui.. I am not sure how the migration can fix this. I Guess this is an issue with MySQL?
You may develop app on server where sql_mode "" and deploy to this animal and then everything brakes apart... columns that are nullable or not declared as nullable, if you have 'too much data that was trimmed before' now will result in error and stuff like that.
You want unsigned, not unasigned in your migration. You don't need to manually add the index - adding a foreign key will handle that for you.
Make sure you create your foreign keys before you insert any data. Best practice is to make the foreign key field nullable, as NULL is the only value you will be able to use, other than a foreign value.
But you have a typo - as @deringer says 'unasigned' is not valid. I'm surprised this is not the line throwing the error, but it may be that the foreign key constraint is failing because you did not specify 'unsigned' for the column?
Guys is very important the order of migrations you can't create first the table that is setting the foreign key for a table that doesn't exist yet, a quickly solution is to rename the migration file changing the datetime stamp, example:
2016_06_28_185212_create_posts_table.php --> migration that is trying to set the foreign key, but at this point the users table doesn't exist!
2016_06_28_185011_create_users_table.php
So rename datetime segment in order that users table is created first:
2016_06_28_185011_create_posts_table.php --> Now this is created first
2016_06_28_185212_create_users_table.php --> Then you can set the foreign key!
@michaeldyrynda , I know you wrote this 2 years ago , but i am suprised by this line:
Make sure you create your foreign keys before you insert any data. Best >practice is to make the foreign key field nullable, as NULL is the only value >you will be able to use, other than a foreign value.
Is this really the case? I never knew this and i'm pretty suprised. Can you tell me what advantages this gives?
@Chrizzmeister if you had a user_id column in a table and later decided to add a foreign key constraint to it, any records that either had no value or the value of a non-existent foreign id i.e. a deleted user would cause adding of the foreign key constraint to fail.