Migration: impossible d'ajouter une contrainte de clé étrangère dans laravel
J'essaie de créer des clés étrangères dans Laravel cependant, lorsque je migre ma table en utilisant artisan, l'erreur suivante est générée:
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint (SQL
: alter table `priorities` add constraint priorities_user_id_foreign foreign
key (`user_id`) references `users` (`id`))
Mon code de migration est le suivant:
fichier de migration des priorités
public function up()
{
//
Schema::create('priorities', function($table) {
$table->increments('id', true);
$table->integer('user_id');
$table->foreign('user_id')->references('id')->on('users');
$table->string('priority_name');
$table->smallInteger('rank');
$table->text('class');
$table->timestamps('timecreated');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
//
Schema::drop('priorities');
}
fichier de migration des utilisateurs
public function up()
{
//
Schema::table('users', function($table)
{
$table->create();
$table->increments('id');
$table->string('email');
$table->string('first_name');
$table->string('password');
$table->string('email_code');
$table->string('time_created');
$table->string('ip');
$table->string('confirmed');
$table->string('user_role');
$table->string('salt');
$table->string('last_login');
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
//
Schemea::drop('users');
}
Toute idée de ce que j'ai fait de mal, je veux l'obtenir maintenant, car j'ai beaucoup de tables à créer, par exemple. Utilisateurs, clients, projets, tâches, statuts, priorités, types, équipes. Idéalement, je veux créer des tables contenant ces données avec les clés étrangères, i..e clients_project et project_tasks etc.
J'espère que quelqu'un pourra m'aider à démarrer.
Merci d'avance.
Ajoutez-le en deux étapes, et il est bon de le faire non signé également:
public function up()
{
Schema::create('priorities', function($table) {
$table->increments('id', true);
$table->integer('user_id')->unsigned();
$table->string('priority_name');
$table->smallInteger('rank');
$table->text('class');
$table->timestamps('timecreated');
});
Schema::table('priorities', function($table) {
$table->foreign('user_id')->references('id')->on('users');
});
}
La question a déjà répondu, mais espérons que cela pourrait aider quelqu'un d'autre.
Cette erreur s'est produite pour moi car j'ai créé la table de migration avec la clé étrangère avant que la clé n'existe en tant que clé primaire dans sa table d'origine. Les migrations sont exécutées dans l'ordre de création, comme indiqué par le nom de fichier généré après l'exécution de migrate:make. Par exemple. 2014_05_10_165709_create_student_table.php.
La solution consistait à renommer le fichier avec la clé étrangère en un temps antérieur à celui avec la clé primaire, comme recommandé ici: http://forumsarchive.laravel.io/viewtopic.php?id=10246
Je pense que je devais aussi ajouter dans $table->engine = 'InnoDB';
Dans mon cas, le problème était lié au moment de la migration. Faites attention lorsque vous créez des migrations, créez d'abord la migration enfant plutôt que la migration de base. Parce que si vous créez d'abord la migration de base avec votre clé étrangère, la table enfant sera recherchée et il n'y aura pas de table qui lève une exception.
En outre:
Lorsque vous créez une migration, son horodatage commence au début. disons que vous avez créé un fichier de migration cat afin qu'il ressemble à 2015_08_19_075954_the_cats_time.php et qu'il comporte ce code
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class TheCatsTime extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('cat', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
$table->date('date_of_birth');
$table->integer('breed_id')->unsigned()->nullable();
});
Schema::table('cat', function($table) {
$table->foreign('breed_id')->references('id')->on('breed');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('cat');
}
}
Et après la création de la table de base, vous créez une autre migration breed qui est une table enfant. Elle possède son propre horodatage de création et son horodatage . Le code ressemblera à ceci:
<?php
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Database\Migrations\Migration;
class BreedTime extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::create('breed', function (Blueprint $table) {
$table->increments('id');
$table->string('name');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('breed');
}
}
il semble que ces deux tables sont correctes mais lorsque vous exécutez php artisan migrate . Il lève une exception car la migration créera d’abord la table de base dans votre base de données car vous avez d’abord créé cette migration et que notre table de base contient une contrainte de clé étrangère qui recherche la table enfant et la table enfant n’existe pas, ce qui est probablement une exception..
Alors:
Créez d'abord la migration de la table enfant.
Créez une migration de table de base après la création d'une migration enfant.
artisan php migrer.
fait ça va marcher
Dans mon cas, je modifie simplement l'ordre. Les migrations sont exécutées manuellement. Les utilisateurs de la table sont donc créés en premier.
Dans le dossier base de données/migrations/votre nom de fichier de migration ont le format suivant: Year_month_day_hhmmss_create_XXXX_table.php
Il suffit de renommer le fichier utilisateur afin que la date de création de votre tableau de priorités de table soit définie plus tard que la date utilisateur (même une seconde plus tard, cela suffit)
Dans mon cas, le problème était que la migration générée automatiquement pour la table users avait pour valeur
...
$table->bigIncrements('id');
...
J'ai donc dû changer le type de colonne
$table->bigInteger('id');
faire ma migration avec la clé étrangère travail.
Ceci avec laravel 5.8.2
Dans laravel 5.8, users_table utilise le type de données bigIncrements('id') pour la clé primaire. Ainsi, lorsque vous souhaitez faire référence à une contrainte de clé étrangère, votre colonne user_id doit être de type unsignedBigInteger('user_id').
L'utilisation de Laravel 5.3 présentait le même problème.
La solution consistait à utiliser unsignedInteger au lieu de integer ('name') -> unsigned ().
Donc c'est ce qui a fonctionné
$table->unsignedInt('column_name');
$table->foreign('column_name')->references('id')->on('table_name');
Cela a fonctionné parce que lorsque integer ('name') -> unsigned, la colonne créée dans la table avait une longueur de 11, mais lorsqu’il utilisait unsigedInteger ('name'), la colonne avait une longueur. dix.
La longueur 10 est la longueur des clés primaires lors de l’utilisation de Laravel afin que la longueur des colonnes corresponde.
Pour l’ajout de la contrainte de clé étrangère dans laravel, les éléments suivants ont fonctionné pour moi:
Créez la colonne comme clé étrangère comme suit:
$ table-> entier ('nom_colonne') -> unsigned ();Ajouter la ligne de contrainte immédiatement après (1), c.-à-d.
$ table-> entier ('nom_colonne') -> unsigned (); $ table-> foreign ('nom_colonne') -> références ('pk_of_other_table') -> on ('autre_table');
Nous ne pouvons pas ajouter de relations, sauf si des tables liées sont créées. Laravel exécute les migrations par ordre de date des fichiers de migration. Donc, si vous voulez créer une relation avec une table qui existe dans le deuxième fichier de migration, cela échoue.
J'ai rencontré le même problème et j'ai donc créé un dernier fichier de migration pour spécifier toutes les relations.
Schema::table('properties', function(Blueprint $table) {
$table->foreign('user')->references('id')->on('users')->onDelete('cascade');
$table->foreign('area')->references('id')->on('areas')->onDelete('cascade');
$table->foreign('city')->references('id')->on('cities')->onDelete('cascade');
$table->foreign('type')->references('id')->on('property_types')->onDelete('cascade');
});
Schema::table('areas', function(Blueprint $table) {
$table->foreign('city_id')->references('id')->on('cities')->onDelete('cascade');
});
Laravel ^ 5.8
À partir de Laravel 5.8 , les talons de migration utilisent la méthode bigIncrements sur les colonnes d'ID par défaut. Auparavant, les colonnes ID étaient créées à l'aide de la méthode des incréments.
Cela n'affectera aucun code existant dans votre projet; Cependant, sachez que les colonnes de clé étrangère doivent être du même type . Par conséquent, une colonne créée à l'aide de la méthode increments ne peut pas référencer une colonne créée à l'aide de la méthode bigIncrements.
Source: Migrations & bigIncrements
Exemple
Imaginons que vous construisiez une application basée sur un rôle simple et que vous deviez faire référence à user_id dans la table PIVOT table "role_user" .
(2019_05_05_112458_create_users_table.php} _
// ...
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('full_name');
$table->string('email');
$table->timestamps();
});
}
2019_05_05_120634_create_role_user_pivot_table.php} _
// ...
public function up()
{
Schema::create('role_user', function (Blueprint $table) {
// this line throw QueryException "SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint..."
// $table->integer('user_id')->unsigned()->index();
$table->bigInteger('board_id')->unsigned()->index(); // this is working
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
});
}
Comme vous pouvez le constater, la ligne commentée lève une exception de requête car, comme indiqué dans les notes de mise à niveau, les colonnes foreign key doivent être du même type , vous devez donc modifier la clé Cet exemple est id_utilisateur) à bigInteger dans utilisateur_rôle table ou changez la méthode bigIncrements en incréments dans utilisateurs table et utilisez la ligne commentée dans le tableau croisé dynamique, à vous de choisir.
J'espère que j'ai pu clarifier ce problème pour vous.
J'avais le même problème avec Laravel 5.8. Après avoir examiné de plus près les documents laravel, d’ailleurs ici Migrations & bigIncrements . J'ai résolu le problème en ajoutant des clés primaires "$ table-> bigIncrements ('id')" à chaque table liée à la table "utilisateurs" et à ses associations. , dans mon cas, la table "rôle" . Enfin, j'avais "$ table-> unsignedBigInteger" pour associer des rôles à des utilisateurs (plusieurs à plusieurs), c'est-à-dire table "rôle_utilisateur" .
1. Users table
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();
});
2. Roles Table
Schema::create('roles', function (Blueprint $table) {
$table->bigIncrements('id');
$table->string('name')->unique();
$table->string('display_name')->nullable();
$table->string('description')->nullable();
$table->timestamps();
});
3. Table role_user
Schema::create('role_user', function (Blueprint $table) {
$table->unsignedBigInteger('user_id');
$table->unsignedBigInteger('role_id');
$table->foreign('user_id')->references('id')->on('users')
->onUpdate('cascade')->onDelete('cascade');
$table->foreign('role_id')->references('id')->on('roles')
->onUpdate('cascade')->onDelete('cascade');
$table->primary(['user_id', 'role_id']);
});
je sais que c’est une vieille question mais assurez-vous que si vous travaillez avec des références, le moteur approprié est défini. définir le moteur innodb pour les deux tables et le même type de données pour les colonnes de référence
$table->engine = 'InnoDB';
Quelques années après la question initiale, en utilisant laravel 5.1, j'ai eu la même erreur, mes migrations ayant été générées par ordinateur avec le même code de date. J'ai parcouru toutes les solutions proposées, puis refactored pour trouver la source d'erreur.
Après les laracasts et la lecture de ces articles, je pense que la réponse correcte est similaire à celle de Vickies, à la différence près qu'il n'est pas nécessaire d'ajouter un appel de schéma séparé. Vous n'avez pas besoin de mettre la table à Innodb, je suppose que laravel le fait maintenant.
Les migrations doivent simplement être correctement chronométrées, ce qui signifie que vous modifierez le code de date dans le nom de fichier pour les tables sur lesquelles vous avez besoin de clés étrangères. Alternativement ou en complément, réduisez le code de date pour les tables ne nécessitant pas de clé étrangère.
L'avantage de la modification du code de date est que votre code de migration sera plus facile à lire et à gérer.
Jusqu'à présent, mon code fonctionne en ajustant le code temporel pour qu'il mette à jour les migrations nécessitant des clés étrangères.
Cependant, j'ai des centaines de tables, donc à la fin, j'ai une dernière table pour les clés étrangères. Juste pour faire avancer les choses. Je suppose que je vais les extraire dans le bon fichier et modifier le code de date au fur et à mesure que je les teste.
Ainsi, un exemple: fichier 2016_01_18_999999_create_product_options_table. Celui-ci a besoin de la table des produits pour être créé. Regardez les noms de fichiers.
public function up()
{
Schema::create('product_options', function (Blueprint $table) {
$table->increments('id');
$table->integer('product_attribute_id')->unsigned()->index();
$table->integer('product_id')->unsigned()->index();
$table->string('value', 40)->default('');
$table->timestamps();
//$table->foreign('product_id')->references('id')->on('products');
$table->foreign('product_attribute_id')->references('id')->on('product_attributes');
$table->foreign('product_id')->references('id')->on('products');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('product_options');
}
la table des produits: il faut d'abord migrer. 2015_01_18_000000_create_products_table
public function up()
{
Schema::create('products', function (Blueprint $table) {
$table->increments('id');
$table->string('style_number', 64)->default('');
$table->string('title')->default('');
$table->text('overview')->nullable();
$table->text('description')->nullable();
$table->timestamps();
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::drop('products');
}
Et enfin, à la fin, le fichier que j’utilise temporairement pour résoudre des problèmes que je vais refactoriser au fur et à mesure que j’écris des tests pour les modèles que j’ai nommés 9999_99_99_999999_create_foreign_keys.php. Ces touches sont commentées au fur et à mesure que je les retire, mais vous comprenez le point.
public function up()
{
// Schema::table('product_skus', function ($table) {
// $table->foreign('product_id')->references('id')->on('products')->onDelete('cascade');
// });
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
// Schema::table('product_skus', function ($table)
// {
// $table->dropForeign('product_skus_product_id_foreign');
// });
Cette erreur est survenue car, alors que la table que j'essayais de créer était InnoDB, la table étrangère à laquelle je tentais de faire le lien était une table MyISAM!
assurez-vous que votre colonne de commande est au-dessus d'une large colonne de colonne de clé
Je veux dire que votre clé étrangère (dans le deuxième tableau) doit être du même type que votre clé principale de Ponter (dans le premier tableau)
votre clé principale de pointeur doit être une méthode add unsigned, laissez-moi vous montrer:
sur votre table de migration FIRST:
$table->increments('column_name'); //is INTEGER and UNSIGNED
sur votre seconde table de migration:
$table->integer('column_forein_name')->unsigned(); //this must be INTEGER and UNSIGNED
$table->foreign('column_forein_name')->references('column_name')->on('first_table_name');
UN AUTRE EXEMPLE POUR VOIR LA DIFFÉRENCE
sur votre table de migration FIRST:
$table->mediumIncrements('column_name'); //is MEDIUM-INTEGER and UNSIGNED
sur votre seconde table de migration:
$table->mediumInteger('column_forein_name')->unsigned(); //this must be MEDIUM-INTEGER and UNSIGNED
$table->foreign('column_forein_name')->references('column_name')->on('first_table_name');
Une chose que j'ai remarquée est que si les tables utilisent un moteur différent de la contrainte de clé étrangère, cela ne fonctionne pas.
Par exemple, si une table utilise:
$table->engine = 'InnoDB';
Et les autres utilisations
$table->engine = 'MyISAM';
générerait une erreur:
SQLSTATE[HY000]: General error: 1215 Cannot add foreign key constraint
Vous pouvez résoudre ce problème en ajoutant simplement InnoDB à la fin de la création de votre table, comme suit:
public function up()
{
Schema::create('users', function (Blueprint $table) {
$table->bigIncrements('id');
$table->unsignedInteger('business_unit_id')->nullable();
$table->string('name', 100);
$table->foreign('business_unit_id')
->references('id')
->on('business_units')
->onDelete('cascade');
$table->timestamps();
$table->softDeletes();
$table->engine = 'InnoDB'; # <=== see this line
});
}
J'ai eu ce problème avec laravel 5.8 et en ajoutant ce code à l'endroit où j'ajoute toujours user_id a fait l'affaire.
$table->unsignedBigInteger('user_id');
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
alors j'ai couru $ php artisan migrate:fresh
Je suis devenu fou, je viens d'avoir une faute de frappe:
unsinged() au lieu de unsigned().
Vous pouvez directement passer un paramètre booléen dans une colonne entière en indiquant qu'il doit être non signé ou non. Dans laravel 5.4 le code suivant a résolu mon problème.
$table->integer('user_id', false, true);
Ici, le deuxième paramètre false indique qu'il ne devrait pas être incrémenté automatiquement et le troisième paramètre true indique qu'il doit être non signé. Vous pouvez conserver la contrainte de clé étrangère dans la même migration ou la séparer. Cela fonctionne à la fois.
Soyez conscient: quand Laravel configure une table en utilisant
$table->increments('id');
qui est standard dans la plupart des migrations, cela va configurer un champ entier non signé. Par conséquent, lorsque vous créez une référence étrangère à partir d'une autre table vers ce champ, assurez-vous que dans la table de référence, définissez le champ sur UnsignedInteger et non (ce que j'avais supposé être) un champ UnsignedBigInteger.
Par exemple: dans le fichier de migration 2018_12_12_123456_create_users_table.php:
Schema::create('users', function (Blueprint $table){
$table->increments('id');
$table->string('name');
$table->timestamps();
Ensuite, dans le fichier de migration 2018_12_12_18000000_create_permissions_table.php, qui redéfinit la référence étrangère aux utilisateurs:
Schema::create('permissions', function (Blueprint $table){
$table->increments('id');
$table->UnsignedInteger('user_id'); // UnsignedInteger = "increments" in users table
$table->boolean('admin');
$table->boolean('enabled');
$table->timestamps();
// set up relationship
$table->foreign('user_id')->reference('id')->on('users')->onDelete('cascade');
}
Dans mon cas, j'ai oublié d'utiliser des parenthèses pour ->unsigned() lorsque j'ai défini la colonne.
Mauvais code: $table->integer('permission_id')->unsigned;
Vrai code: $table->integer('permission_id')->unsigned();
Si simple !!!
si vous créez votre premier fichier de migration 'priorities', Laravel exécute d'abord 'priorities' alors que la table 'users' n'existe pas.
comment il peut ajouter une relation à une table qui n'existe pas!.
Solution: extraire _ codes de clé étrangère de la table 'priorities'. votre fichier de migration devrait être comme ceci:
et ajoutez à un nouveau fichier de migration, ici son nom est create_prioritiesForeignKey_table et ajoutez ces codes:
public function up()
{
Schema::table('priorities', function (Blueprint $table) {
$table->foreign('user_id')
->references('id')
->on('users');
});
}
Dans mon cas, cela ne fonctionnait pas tant que je n'ai pas exécuté la commande
composer dump-autoload
de cette façon, vous pouvez laisser les clés étrangères à l'intérieur du schéma de création.
public function up()
{
//
Schema::create('priorities', function($table) {
$table->increments('id', true);
$table->integer('user_id');
$table->foreign('user_id')->references('id')->on('users');
$table->string('priority_name');
$table->smallInteger('rank');
$table->text('class');
$table->timestamps('timecreated');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
//
Schema::drop('priorities');
}
Cela peut également être votre commande de migration de création. Si vous créez d’abord la table des priorités, puis celle des utilisateurs, elle se trompe. En raison de la première migration, recherche du tableau des utilisateurs. Donc, vous devez changer l'ordre de la migration sur
app/database/migrations
annuaire
Je pense qu’une chose manque dans les réponses et corrigez-moi si je me trompe, mais les clés étrangères doivent être indexées dans le tableau croisé dynamique. Au moins dans mysql, cela semble être le cas.
public function up()
{
Schema::create('image_post', function (Blueprint $table) {
$table->engine = 'InnoDB';
$table->increments('id');
$table->integer('image_id')->unsigned()->index();
$table->integer('post_id')->unsigned()->index();
$table->timestamps();
});
Schema::table('image_post', function($table) {
$table->foreign('image_id')->references('id')->on('image')->onDelete('cascade');
$table->foreign('post_id')->references('id')->on('post')->onDelete('cascade');
});
}
En résumé, la méthode étrangère utilise ALTER_TABLE pour transformer un champ préexistant en clé étrangère. Vous devez donc définir le type de table avant d’appliquer la clé étrangère. Cependant, il n'est pas nécessaire que ce soit dans un appel Schema:: séparé. Vous pouvez faire les deux dans create, comme ceci:
public function up()
{
Schema::create('priorities', function($table) {
$table->increments('id', true);
$table->integer('user_id')->unsigned();
$table->foreign('user_id')->references('id')->on('users');
$table->string('priority_name');
$table->smallInteger('rank');
$table->text('class');
$table->timestamps('timecreated');
});
}
Notez également que le type de user_id est défini sur non signé pour correspondre à la clé étrangère.
Dans mon cas, le responsable de la migration pour créer la table référencée n'a pas été exécuté correctement. Il n'y avait donc pas de table dans la base de données à référencer par la clé étrangère.
Vérifiez si la table existe et sinon, vérifiez la migration de cette table.
Pour moi, la colonne de table référencée par ma table enfant n'a pas été indexée.
Schema::create('schools', function (Blueprint $table) {
$table->integer('dcid')->index()->unque();
$table->integer('school_number')->index(); // The important thing is that this is indexed
$table->string('name');
$table->string('abbreviation');
$table->integer('high_grade');
$table->integer('low_grade');
$table->timestamps();
$table->primary('dcid');
});
Schema::create('students', function (Blueprint $table) {
$table->increments('id');
$table->integer('dcid')->index()->unique()->nullable();
$table->unsignedInteger('student_number')->nullable();
$table->integer('schoolid')->nullable();
$table->foreign('schoolid')->references('school_number')->on('schools')->onDelete('set null');
// ...
});
Ignorez le nom terrible, il provient d'un autre système terriblement conçu.
Cela a résolu mon problème
La table ou l'index auquel la contrainte fait référence n'existe pas encore
comme @haakym a dit que la seule chose à faire est de renommer le nom xxx_xx_xx_xxxxxx_create_users_table et de définir une date de publication antérieure à xxx_xx_xx_xxxxxxxcrée
n'oubliez pas d'utiliser $table->engine = 'InnoDB'; si vous utilisez MySql car MyISAM ne prend pas en charge les clés étrangères de contrainte
Ajout à la solution unsigned () lors de la création d'une base de données utilisant InnoDB comme moteur des tables. Assurez-vous que la table étrangère a été créée avant les tables qui dépendront de la table étrangère.
Illustration
Cas 1 (tables fraîches)
Supposons que votre table de commentaires dépend de post table (table étrangère). Vous devez créer la table post avant de créer la table de commentaires.
Cas 2 (tables existantes)
Supposons que votre table de commentaires ait été créée avant votre table de postages . Créez votre post table dans un nouveau fichier de migration, puis ajoutez les clés étrangères de la table comment dans un nouveau fichier de migration que vous créez après la création de la migration de post table.
PS
Je suppose que vous utilisez laravel
Vous devriez écrire de cette façon
public function up()
{
Schema::create('transactions', function (Blueprint $table) {
$table->bigIncrements('id');
$table->float('amount', 11, 2);
$table->enum('transaction type', ['debit', 'credit']);
$table->bigInteger('customer_id')->unsigned();
$table->timestamps();
});
Schema::table('transactions', function($table) {
$table->foreign('customer_id')
->references('id')->on('customers')
->onDelete('cascade');
});
}
Le champ de clé étrangère devrait être non signé, espérons que cela aide !!
si vous avez besoin de créer une clé étrangère dans vos priorités de table, puis
$table->integer('user_id')->unsigned();
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
vous devez créer la colonne non signée pour la faire fonctionner.
Si aucune des solutions ci-dessus ne fonctionne pour les débutants, vérifiez si les deux ID ont le même type: les deux sont integer ou les deux sont bigInteger, ... Vous pouvez avoir quelque chose comme ceci:
Table principale (utilisateurs par exemple)
$table->bigIncrements('id');
Table des enfants (priorités par exemple)
$table->unsignedInteger('user_id');
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
Cette requête va échouer car users.id est un BIG INTEGER alors que priorities.user_id est une INTEGER.
La bonne requête dans ce cas serait la suivante:
$table->unsignedBigInteger('user_id');
$table->foreign('user_id')->references('id')->on('users')->onDelete('cascade');
Je pense: la clé de référence doit être "index" . Par exemple: (bas)
public function up()
{
Schema::create('clicks', function (Blueprint $table) {
$table->increments('id');
$table->string('viewer_id');
$table->integer('link_id')->index()->unsigned();
$table->string('time');
$table->timestamps();
});
Schema::table('clicks', function($table) {
$table->foreign('link_id')->references('id')->on('links')->onDelete('cascade');
});
}
bonne chance.