Laravel 4 : chapitre 13 : Les bases de données 1/3
Nous allons à présent aborder un aspect important avec a gestion des bases de données. Laravel 4 est bien équipé dans ce domaine, comme nous allons le voir. Vous pouvez accéder à des bases : MySQL, SQLite, SQL server et PostgreSQL.
Configuration
La configuration est simple et se passe dans le fichier app/config/database.php. Vous précisez le type de base :
'default' => 'mysql',
Par défaut on a mysql, mais vous pouvez aussi mettre sqlite, pgsql ou sqlsrv. Ensuite vous précisez les paramètres. Je vais prendre le cas le plus classique avec MySQL :
'mysql' => array( 'driver' => 'mysql', 'host' => 'localhost', 'database' => 'laravel', 'username' => 'root', 'password' => '', 'charset' => 'utf8', 'collation' => 'utf8_unicode_ci', 'prefix' => '', ),
J’ai défini une base nommée laravel pour les tests. Laravel 4 sait faire beaucoup de choses mais pas créer des bases, vous devez donc la créer vous-même par exemple avec phpMyAdmin.
Migration
Laravel possède un outil bien pratique pour gérer la structure d’une base de données : migration. C’est un outil en ligne de commande qui fait partie des commandes d’artisan que nous avons déjà précédemment vu. Nous allons l’utiliser pour créer une table dans notre base. La première chose à faire est de créer une migration. C’est quoi ce truc ? Tout simplement un peu de code qui va nous permettre d’intervenir sur la structure de la base, de faire des modifications et de pouvoir revenir en arrière si besoin. Voyons ce que nous permet de faire cet outil :
Et plus précisément ses paramètres utilisables :
Commençons par créer une migration :
Bon apparemment tout c’est bien passé mais où elle est cette migration ? Regardez ici :
Un fichier a été créé avec un nom composé d’un timestamp et du nom que nous avons donné à la migration. De cette façon il est peu probable de se retrouver avec un conflit de nom en cas de travail en équipe Voyons ce fichier :
<?php use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateEssences extends Migration { /** * Run the migrations. * * @return void */ public function up() { // } /** * Reverse the migrations. * * @return void */ public function down() { // } }
On y trouve une classe CreateEssences qui hérite de la classe Migration. On trouve aussi deux méthodes publiques up et down. C’est à nous de créer le code de ces méthodes. Dans up nous devons mettre le code qui va créer une modification dans la structure de la base, et dans down le code qui va faire l’inverse.
Le Schema builder
Pour créer le code de migration nous allons être aidés par la classe Schema d’illuminate. Cette classe permet de créer et de supprimer facilement des tables, des colonnes et des index. Voyons ça de plus près avec un exemple simple :
public function up() { Schema::create('essences', function($table) { $table->increments('id'); $table->string('nom_vulgaire', 100); $table->string('nom_latin', 100); $table->text('description'); }); }
La syntaxe est si simple qu’elle se passe presque de commentaires. La méthode create permet de créer une table. On transmet le nom de la table à une fonction anonyme qui permet de définir les colonnes. Vous pouvez trouver toutes les possibilités de types de colonnes dans la documentation. Notez que Eloquent a besoin que chaque table ait une clé primaire numérique nommée id pour bien fonctionner (ce n’est pas indispensable mais ça simplifie la syntaxe). Maintenant nous allons activer la migration pour créer notre table :
On nous dit que la migration s’est bien effectuée. Allons voir ça. Nous trouvons deux tables dans notre base : essences et migrations. La première est celle que nous avons créée :
Elle comporte exactement ce que nous avons prévu pour elle. La seconde sert à la gestion des migrations. Maintenant nous devons nous occuper de l’action inverse de notre migration, autrement dit la suppression de la table :
public function down() { Schema::drop('essences'); }
Il ne reste plus qu’à commander le rollback :
Et vous pouvez vérifier que la table a bien été supprimée. Comme nous avons besoin de la table pour la suite faites à nouveau une migration pour la recréer.
Vous pouvez ajouter 2 options (–table= et –create) dans votre migration pour obtenir une architecture de code plus complète :
Vous obtenez ce code :
<?php use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateEssencesTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('essences', function(Blueprint $table) { $table->increments('id'); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('essences'); } }
Des données d’exemple
Il existe aussi un moyen simple pour générer des données d’exemple. Créez un fichier app/database/seeds/EssenceTableSeeder.php avec ce code (nous verrons en détail la syntaxe pour la modification des données dans une table) :
class EssenceTableSeeder extends Seeder { public function run() { DB::table('essences')->insert( array( array( 'nom_vulgaire' => 'Basilic exotique', 'nom_latin' => 'Ocimum basilicum ssp basilicum', 'description' => 'Cette huile essentielle est antibactérienne...' ), array( 'nom_vulgaire' => 'Bergamotier', 'nom_latin' => 'Citrus bergamia', 'description' => 'Cette huile essentielle est...' ) ) ); } }
Il faut aussi modifier le fichier app/database/seeds/DatabaseSeeder.php pour appeler votre classe :
class DatabaseSeeder extends Seeder { public function run() { $this->call('EssenceTableSeeder'); } }
Lancez ensuite cette commande de migration :
Allez voir dans votre base le résultat :
On peut se poser une question : pourquoi ne pas faire cette opération dans la migration ? On pourrait effectivement le faire et ça fonctionnerait mais il est bon de bien séparer les fonctionnalités. La migration a pour but d’intervenir au niveau de la structure de la base alors que les seeds se contentent d’en modifier le contenu. Vous pourrez me dire aussi que le contenu sera renseigné au fil du temps à partir d’autres interfaces (administration, formulaire…) mais il y a parfois des données qui doivent être renseignées à la création d’un site : une liste de villes, des codes postaux, un compte administrateur, des catégories… Toutes ces données initiales se trouverons ici à leur place.
Les modifications ultérieures
Et la suite ? Imaginez que vous voulez faire une modification dans une de vos tables, devez-vous faire un rollback, modifier le schéma et faire une nouvelle migration ? Bon vous aboutirez bien sûr au résultat mais si vous avez déjà entré des données vous n’allez pas apprécier de les perdre dans la manœuvre . Il est possible de faire une nouvelle migration en effectuant juste la modification nécessaire. Par exemple vous voulez rendre unique la ligne du nom latin :
public function up() { Schema::table('essences', function($table) { $table->unique('nom_latin', 'essences_nom_latin_unique'); }); }
Sans oublier la manœuvre inverse :
public function down() { Schema::table('authors', function($table) { $table->dropUnique('essences_nom_latin_unique'); }); }
Scénario de migrations
Comme le processus de migration n’est pas toujours bien perçu je vous propose un petit scénario pour passer en revue les commandes disponibles. Partons d’une installation vierge de Laravel.
Installation
La première commande disponible est migrate:install qui est destinée à créer la table des migrations dans la base :
Cette opération n’est pas indispensable parce que si cette table n’existe pas elle sera créée lors de la première migration effectuée.
Première migration
Créons maintenant notre première migration. Imaginons que nous voulons une table d’auteurs. On commence par créer la migration en lui donnant un nom explicite et tant qu’à faire on utilise les options pour générer le maximum de code :
Le fichier est créé :
Avec ce code :
use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateAuteursTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('auteurs', function(Blueprint $table) { $table->increments('id'); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('auteurs'); } }
Ajoutons un champ, par exemple le nom de l’auteur :
Schema::create('auteurs', function(Blueprint $table) { $table->increments('id'); $table->timestamps(); $table->string('nom'); });
Et maintenant activons cette migration :
La table « auteurs » est bien créée avec les champs attendus :
Ajout d’un champ
Maintenant on se rend compte qu’on a oublié le champ « email », comment l’ajouter ? On pourrait faire un rollback pour supprimer la table, faire la modification et relancer la migration. Mais il est plus simple de créer une nouvelle migration pour cet ajout :
Rappelez-vous que vous donnez le nom que vous voulez à la migration, faites en sorte que ce soit explicite pour vous. On a donc un nouveau fichier :
Avec ce code :
use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class AddEmailToAuteurs extends Migration { /** * Run the migrations. * * @return void */ public function up() { // } /** * Reverse the migrations. * * @return void */ public function down() { // } }
Ajoutons le code pour notre email :
public function up() { Schema::table('auteurs', function($table) { $table->string('email', 64); }); } .... public function down() { Schema::table('auteurs', function($table) { $table->dropColumn('email'); }); }
Et lançons cette migration :
Retour en arrière
Finalement on se rend compte qu’on a pas besoin de l’email, alors on supprime la dernière migration :
On a bien la suppression de l’email dans la base.
Ajout d’une table
Maintenant on veut ajouter une table des livres :
Avec encore le code de base :
use Illuminate\Database\Schema\Blueprint; use Illuminate\Database\Migrations\Migration; class CreateLivresTable extends Migration { /** * Run the migrations. * * @return void */ public function up() { Schema::create('livres', function(Blueprint $table) { $table->increments('id'); $table->timestamps(); }); } /** * Reverse the migrations. * * @return void */ public function down() { Schema::drop('livres'); } }
Ajoutons un champ :
Schema::create('livres', function(Blueprint $table) { $table->increments('id'); $table->timestamps(); $table->string('titre'); });
Et lançons la migration :
Remarquez que 2 migrations ont eu lieu, et c’est logique. puisqu’on avait fait un rollback pour l’email, cette migration existe toujours et n’est pas effectuée, donc la commande migrate l’active. Si on avait voulu éviter cela il aurait suffit de supprimer le fichier correspondant qui n’avait plus de raison d’être si cet email était vraiment à supprimer. On trouve bien la table des livres avec les champs attendus :
Épurer une migration
Revenons sur le cas de l’email. On se rend compte que finalement on en voulait pas, comment le supprimer maintenant ? Faisons deux rollback :
Maintenant supprimons le fichier de la migration de l’email :
Et faisons une migration :
Nous obtenons bien ce que nous voulions : suppression de l’email et création de la table des livres.
Rafraichissement des migrations
Il est parfois utile de relancer toutes les migration (par exemple si on a effectué quelques modifications dans les fichiers des migrations), pour faire cela il y a la commande refresh :
On a les rollback dans l’ordre et les migrations qui se relancent, aussi dans l’ordre.
Suppression de toutes les migrations
Enfin on peut aussi vouloir supprimer toutes les migrations effectuées, on le fait avec la commande reset :
Cette fois on a que les rollback.
***
Nous avons donc vu comment gérer la structure d’une base de données, nous verrons dans une prochaine étape comment manipuler des données.
15 commentaires
Dan
bonjour, moi j’ai bien definit les migrations et les shemas , mais je ne vois tou tes les tables crée dans la base de données
fluf
Bonjour !
Tout d’abord, je voulais vous remercier pour ce tuto sur Laravel, bien clair et précis.
Ceci dit, en lisant ce chapitre, il me vient une question : n’étant pas adepte des frameworks, j’ai tendance à critiquer leur utilisation au détriment du code dur… Bref, là où je veux en venir, c’est que je ne comprends pas l’avantage de l’utilisation de Migration pour l’administration des bases de données. Autant, dans les derniers chapitres, grâce à vous, j’ai compris l’utilité d’énormément de choses présentes dans les frameworks, autant, là, ça bloque… :/
Auriez-vous une explication pour moi, s’il vous plait ?
Merci d’avance !
bestmomo
Bonjour,
Les migrations permettent une gestion bien pratique d’une base en gardant une trace des modifications. D’autre part il existe des shemas designer et des générateurs qui simplifient la création. Je les trouve bien plus pratiques que de gérer la base avec un outil externe.
fluf
Oui, c’est vrai, vous avez raison… Mais n’est-il pas plus lourd de créer une fonction avec Migration, et de la remplir en fonction de nos besoins, plutôt que de directement envoyer une fonction SQL au moment utile ?
bestmomo
Lorsqu’on utilise les générateurs la création des migrations est automatisée et ce n’est pas plus lourd. D’autant que ces générateur peuvent créer en plus les modèles et les contrôleurs.
fluf
Oui, je vois. Merci beaucoup pour toutes ces explications ! 🙂
weip
Juste pour te dire que le générateur de create et drop automatique a changé avec Laravel 4.1, mais je ne peux pas mettre le code ici dans les commentaires ça plante toujours. Je ne sais pas si ton site bloque les keyword create ou drop mais ça ne marche pas. Bref, nouvelle syntaxe de 4.1 disponible ici http://stackoverflow.com/questions/20597793/migration-doesnt-automatically-create-shema
bestmomo
Merci pour l’info, je mettrai ça d’aplomb rapidement.
J’ai trouvé tes commentaires marqués comme spams à cause de l’IP du serveur. Je vais voir de plus près les réglages…
christoff
Bonjour à tous,
Certains d’entre-vous obtiendront peut-être le message d’erreur suivant si ils tentent la commande php artisan migrate:
[PDOException]
SQLSTATE[HY000] [2002] Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock'
Cela a été mon cas sur mon serveur local XLAMP.
La solution est la suivante, il faut ajouter une ligne dans le fichier config/database.php:
'mysql' => array(
...
'unix_socket' => '/opt/lampp/var/mysql/mysql.sock',
),
bestmomo
Tu as essayé en changeant juste localhost en 127.0.0.1 dans app/config/database.php ?
christoff
Avec 127.0.0.1, cela ne fonctionne pas sur ma configuration. Seulement avec ce code:
'host' => 'localhost',
'unix_socket' => '/opt/lampp/var/mysql/mysql.sock',
Remarque: la ligne unix_socket, c’est pour artisan
Car query builder et Eloquent n’en ont pas besoin.
J’utilise Laravel4.1 et XLAMPP.
Donc c’est possible que dans une autre configuration il n’y ait pas de problème.
maxgosset
bonjour et merci pour la reponse
le pb c’est que quand je fais un rollback , il me vire toutes mes tables ( sauf si je vire tous les fichiers du dossiers migration )
et je suis toujours bloqué aussi avec la table « migration » qui se crée automatiquement
en fait il me dit que celle ci existe deja et donc je dois aussi virer la table « migration » avant de faire un migrate
je sais pas si j’ai ete clair
en tout cas merci pour ton aide
bestmomo
J’ai ajouté un chapitre de scénario de migrations pour clarifier ce point, en espérant qu’il est suffisamment explicite…
maxgosset
bonjour , comment dire a artisan de n’exporter qu’une seule table
je m’explique : je suis actuellement en plein projet , et j’ai donc cree toutes mes tables sauf une et je voudrais l’ajouter
sauf que quand j’utilise la commande php artisan migrate , il me dit que certaines tables existent deja ( toute sauf une en fait ) c’est pourquoi je me demandais si il etait possible de migrer qu’une seule table
bestmomo
Pour ajouter une table il y a deux solutions :
– créer une nouvelle migration pour cette table (c’est le plus simple et la méthode à privilégier),
– faire un roll-back de la dernière migration et ensuite compléter la migration en conséquence avant de la relancer (mais évidemment dans ce cas on perd toutes les données qui ont été éventuellement enregistrées).
La commande « refresh » peut être pratique, elle supprime toutes les migrations et les relance…