J'essaye de migrer une table d'utilisateurs dans Laravel. Lorsque j'exécute ma migration, j'obtiens cette erreur:
[Illuminate \ Database \ QueryException] SQLSTATE [42000]: Erreur de syntaxe ou violation d'accès: 1071 La clé spécifiée était trop longue; la longueur maximale de la clé est de 767 octets (SQL: alter table
users
add unique users_email_uniq (
ma migration est la suivante:
Schema::create('users', function(Blueprint $table)
{
$table->increments('id');
$table->string('name', 32);
$table->string('username', 32);
$table->string('email', 320);
$table->string('password', 64);
$table->string('role', 32);
$table->string('confirmation_code');
$table->boolean('confirmed')->default(true);
$table->timestamps();
$table->unique('email', 'users_email_uniq');
});
Après quelques recherches sur Google, je suis tombé sur ce rapport de bogue où Taylor dit que vous pouvez spécifier la clé d'index comme deuxième paramètre de unique()
, ce que j'ai fait. Cela donne toujours l'erreur. Qu'est-ce qui se passe ici?
Réponses:
Spécifiez une longueur plus petite pour votre e-mail:
Quelle est la valeur par défaut, en fait:
Et tu devrais être bon.
Pour Laravel 5.4, vous pouvez trouver une solution dans ce Laravel 5.4: La clé spécifiée était une erreur trop longue, Laravel News post:
Comme indiqué dans le guide Migrations pour résoudre ce problème, tout ce que vous avez à faire est de modifier votre fichier AppServiceProvider.php et, dans la méthode de démarrage, définissez une longueur de chaîne par défaut:
la source
254
donc probablement la peine de garder cela à l'esprit, donc je validerais probablement l'unicité à l'aide du validateur dans ce cas.\Illuminate\Database\Schema\Builder::defaultStringLength(191);
pour le chemin de référence de fonction correctMise à jour 1
Depuis Laravel 5.4, ces changements ne sont plus nécessaires.
Mise à jour 2
Les versions de production actuelles de MariaDB NE prennent PAS en charge ce paramètre par défaut globalement. Il est implémenté dans MariaDB 10.2.2+ par défaut .
Solution
Et si vous voulez intentionnellement utiliser le
utf8mb4
support multi-octets UTF8 par défaut futur correct (à partir de Laravel 5.4) pour 😀 alors commencez à corriger fix la configuration de votre base de données.Dans Laravel
config/database.php
définir:DYNAMIC
permet de stocker de longs index clés .Paramètres du serveur (inclus par défaut dans MySQL 5.7.7+ / MariaDB 10.2.2+):
Pour les clients:
Et puis ARRÊTEZ votre serveur MySQL / MariaDB. Après cela, START. Le redémarrage à chaud peut ne pas fonctionner.
Vous avez maintenant Laravel 5.x avec le support UTF8.
la source
database.php
fichier de configuration et cela aura un impact sur le projet Laravel local. Assurez-vous de ladelete
base de données avant d'apporter des modifications et créez-la avec de nouveaux paramètres. Vous devez modifier lemy.cnf
fichier de configuration uniquement pour les modifications globales côté serveur (actuellement toutes les nouvelles installations utilisentutf8mb4
).options={"row_format"="DYNAMIC"}
à votre@Table
annotation.Si vous êtes sur ou mis à jour vers Laravel 5.4 Cela a fonctionné pour moi;
Juste 1 changement. dans AppServiceProvider.php
Comme mentionné dans le guide de migration https://laravel.com/docs/master/migrations#creating-indexes
la source
Si quelqu'un d'autre tombe sur cette réponse comme je l'ai fait, mais pour une raison différente, vous pouvez vérifier votre jeu de caractères / collation Laravel DB.
J'installais une application (Snipe-IT) et j'avais configuré la configuration de la base de données Laravel pour utiliser ce qui suit:
La suppression
mb4
des deux chaînes a résolu le problème, même si je pense que la réponse d'Antonio est la vraie solution au problème.la source
Cela a fonctionné pour moi:
la source
Supprimez mb4 de charset et collation de config / database.php, puis il s'exécutera avec succès.
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
la source
Pour laravel 5.6
Cette solution résout mon problème,
allez à
config/database.php
trouver le code ci-dessous
Changer ces deux champs
Avec ça
la source
J'ai rencontré le même problème et je l'ai résolu en ajoutant les deux lignes ci-dessous dans mon app / database.php
Mon fichier ressemble à ci-dessous:
la source
Pour laravel 5.4, éditez simplement le fichier
la source
la source
j'ai eu le même problème et j'utilise un wamp
Solution: ouvrez le fichier: config / database.php
Merci
la source
Dans le fichier config / database.php où:
Changez cette ligne en ceci:
la source
Pour Laravel> = 5,6 utilisateurs
Ouvrir le
AppServiceProvider.php
fichierUtilisez la classe suivante
Ensuite, à l'intérieur de la
boot
méthode, ajoutez la ligne suivantela source
J'ai ajouté à la migration elle-même
oui, je sais que je dois en tenir compte à chaque migration, mais je préférerais cela plutôt que de l'avoir caché dans un fournisseur de services totalement indépendant
la source
Si quelqu'un a ce problème même après l'avoir fait, les changements mentionnés ci-dessus. Pour un exemple, dans mon cas, j'ai fait les changements ci-dessous,
Mais cela ne fonctionnerait pas tout de suite pour deux raisons. Premièrement, si vous utilisez lumen au lieu de laravel, vous devrez peut-être d'abord décommenter cette ligne dans votre fichier app.php.
Et puis vous devez créer à nouveau le script de migration avec la commande artisan,
Depuis, seules les modifications que vous avez apportées à ServiceProvider fonctionneront.
la source
pour laravel 5.7, écrivez ce code dans appserviceprovider.php
la source
Remplacez le jeu de caractères de 'utf8mb4' par 'utf8' et
classement de 'utf8mb4_unicode_ci' à 'utf8_unicode_ci'
dans le fichier config / database.php
Cela a fonctionné pour moi.
la source
Laravel utilise le
utf8mb4
jeu de caractères par défaut, qui inclut la prise en charge du stockage des «emojis» dans la base de données. Si vous exécutez une version de MySQL antérieure à la version 5.7.7 ou MariaDB antérieure à la version 10.2.2, vous devrez peut-être configurer manuellement la longueur de chaîne par défaut générée par les migrations afin que MySQL crée des index pour eux. Vous pouvez configurer cela en appelant laSchema::defaultStringLength
méthode dans votreAppServiceProvider
:Vous pouvez vérifier
https://laravel-news.com/laravel-5-4-key-too-long-error https://laravel.com/docs/5.5/migrations#indexes
la source
C'est parce que Laravel 5.4 utilise utf8mb4 qui prend en charge le stockage des emojis.
Ajoutez ceci dans votre app \ Providers \ AppServiceProvider.php
et vous devriez être prêt à partir.
la source
Si vous êtes sur ou mis à jour vers Laravel 5.4 et la dernière version, cela fonctionne;
Juste 1 changement dans AppServiceProvider.php
la source
Je voudrais souligner que quelque chose que j'ai manqué ...
Je suis nouveau chez Laravel, et je n'ai pas copié le "use Illuminate ....." parce que je n'ai vraiment pas payé d'attention, car juste au-dessus du démarrage de la fonction, vous avez déjà une déclaration d' utilisation .
J'espère que ça aide n'importe qui
la source
\
J'ai eu un problème, changez la configuration de la 'config / base de données'
garder le même modèle dans la base de données.
J'ai alors donné la commande
la source
Le 24 octobre 2016, Taylor Otwell, l'auteur de Laravel, a été annoncé sur Twitter
qui avant la version 5.4 le jeu de caractères était
utf8
Au cours de ce siècle, de nombreuses applications Web incluent le chat ou une plate-forme quelconque pour permettre à leurs utilisateurs de converser, et de nombreuses personnes aiment utiliser des emoji ou des smileys. et ce sont des sortes de super caractères qui nécessitent plus d'espaces pour être stockés et qui n'est possible qu'en utilisant
utf8mb4
comme jeu de caractères . C'est la raison pour laquelle ils migrentutf8mb4
uniquement à des fins spatiales.si vous recherchez dans la
Illuminate\Database\Schema\Builder
classe, vous verrez que le$defaultStringLength
est défini sur 255 , et pour modifier cela, vous pouvez procéder à travers laSchema
façade et appeler ladefaultStringLength
méthode et transmettre la nouvelle longueur.pour effectuer ce changement, appelez cette méthode dans votre
AppServiceProvider
classe qui se trouve dans le sous-répertoire app \ fournisseurs comme ceciJe suggérerai d'utiliser 191 comme valeur simplement parce que MySQL prend en charge 767 octets, et parce
767 / 4
que c'est le nombre d'octets pris par chaque caractère multi-octets que vous obtiendrez191
.Pour en savoir plus, cliquez ici Le jeu de caractères utf8mb4 (codage Unicode UTF-8 4 octets) sur le nombre de colonnes de table et la taille des lignes
la source
191
nombre magique.SOLUTION:
Commencez par changer le defaultStringLength en 191, dans le fichier app \ Providers \ AppServiceProvider.php :
Ensuite, modifiez le jeu de caractères et les valeurs de classement comme suit, dans config \ database.php :
( lien pour connaître le jeu de caractères MariaDB )
la source
Aller à votre
config/database.php
et changer le jeu de caractères et la collation de utf8mb4 à utf8Mon problème a été résolu en utilisant cette méthode, bonne chance mec!
la source
Vous n'aurez pas ce problème si vous utilisez MySQL 5.7.7+ ou MariaDB 10.2.2+.
Pour mettre à jour MariaDB sur votre Mac en utilisant Brew, commencez par dissocier l'actuel:
brew unlink mariadb
puis installez-en un de développement en utilisantbrew install mariadb --devel
Une fois l'installation terminée, arrêtez / démarrez le service en cours d'exécution:
brew services stop mariadb brew services start mariadb
La version de développement actuelle est 10.2.3. Une fois l'installation terminée, vous n'aurez plus à vous en soucier et vous pouvez utiliser utf8mb4 (qui est maintenant une valeur par défaut dans Laravel 5.4) sans revenir à utf8 ni modifier AppServiceProvider comme proposé dans la documentation de Laravel: https: // laravel .com / docs / master / releases # laravel-5.4 ( faites défiler jusqu'à: Migration Default String Length )
la source
Je viens d'installer MariaDB 10.2.4 RC, lancé un nouveau projet vierge Laravel 5.4 et la migration par défaut (colonnes varchar (255)) fonctionne.
Pas besoin de changer DB conf et Laravael
config/database.php
. Ainsi, tout comme @scorer l'a noté à propos du comportement par défaut pour 10.2.2+.la source
Tout a été bien décrit dans les autres Anwser vous pouvez voir plus de détails dans le lien ci-dessous (recherche avec la clé 'Index Lengths & MySQL / MariaDB ") https://laravel.com/docs/5.5/migrations
MAIS BIEN CE n'est pas le sujet de cette réponse! le truc, c'est que même en faisant ce qui précède, vous aimerez obtenir une autre erreur (c'est quand vous aimez lancer la
php artisan migrate
commande et à cause du problème de la longueur, l'opération comme coincée au milieu. la solution est ci-dessous , et la table utilisateur est comme créée sans le reste ou pas tout à fait correctement) nous devons rouler bac k. la restauration par défaut ne fonctionnera pas. car l'opération de migration n'aimait pas la finition. vous devez supprimer manuellement les nouvelles tables créées dans la base de données.nous pouvons le faire en utilisant tinker comme ci-dessous:
J'ai moi-même eu un problème avec la table des utilisateurs.
après ça tu es prêt à partir
la source
Définir le moteur de base de données InnoDB:
la source
Si vous avez essayé toutes les autres réponses et qu'elles n'ont pas fonctionné, vous pouvez supprimer toutes les tables de la base de données, puis exécuter la commande migrate en une seule fois à l'aide de cette commande:
la source