Laravel 4

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 :

img33

Et plus précisément ses paramètres utilisables :

img34

Commençons par créer une migration :

img42

Bon apparemment tout c’est bien passé mais où elle est cette migration ? Regardez ici :

img44

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 :

img35

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 :

img36

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 :

img47

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.

Big Boss Vous pouvez ajouter 2 options (–table= et –create) dans votre migration pour obtenir une architecture de code plus complète :

img37

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 :

img79

Allez voir dans votre base le résultat :

img49

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 Tongue Out. 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 :

img73

img74

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 :

img38

Le fichier est créé :

img39

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 :

img40

La table « auteurs » est bien créée avec les champs attendus :

img78

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 :

img79

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 :

img41

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 :

img42

img82

Retour en arrière

Finalement on se rend compte qu’on a pas besoin de l’email, alors on supprime la dernière migration :

img43

img84

On a bien la suppression de l’email dans la base.

Ajout d’une table

Maintenant on veut ajouter une table des livres :

img85

img44

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 :

img45

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 :

img88

É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 :

img90

Maintenant supprimons le fichier de la migration de l’email :

img46

Et faisons une migration :

img91

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 :

img92

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 :

img93

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.

Print Friendly, PDF & Email

15 commentaires

  • 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 !

  • 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',
    ),

      • 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

  • 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…

Laisser un commentaire