Une fois les tables de la base de données créées, il est possible de les modifier. L'utilisation de fichiers de migration est la solution privilégiée.
Si vous avez déjà effectué une migration et que vous devez modifier la structure d'une table, il est préférable de créer un fichier de migration qui modifie la structure d'une table plutôt que de modifier un fichier de migration existant.
Il sera ainsi plus facile de reproduire les modifications sur la base de données en ligne. Ceci permettra également de faire un suivi des versions de la base de données.
Avant d'utiliser un fichier de migration qui modifie la structure d'une table, il faut ajouter une dépendance à notre installation Laravel vers le paquet doctrine/dbal (DataBase Abstraction Layer) :
composer require doctrine/dbal
Ceci ajoutera une ligne dans le fichier composer.json qui est placé directement dans le dossier de votre projet puis téléchargera les fichiers requis dans le dossier vendor.
La ligne qui a été automatiquement ajoutée est surlignée dans cet extrait :
{
"name": "laravel/laravel",
"description": "The Laravel Framework.",
"keywords": ["framework", "laravel"],
"license": "MIT",
"type": "project",
"require": {
"php": ">=5.6.4",
"laravel/framework": "5.4.*",
"doctrine/dbal": "^2.5"
},
Si vous désirez, par exemple, modifier la table produits afin de changer le champ couleur pour couleur_id, qui pointera vers la table couleurs, vous utiliserez la commande :
php artisan make:migration change_produits_couleur_column --table produits
Le nom du fichier de migration peut être n'importe quoi, en autant qu'il décrive bien ce qui est fait dans ce fichier.
Dans le fichier de migration, vous entrerez le code suivant. La modification du nom de la colonne sera faite dans la méthode up(). L'opération inverse sera codée dans la méthode down().
Les ajustements à la table seront faits à l'aide de Schema::table().
class ChangeProduitsCouleurColumn extends Migration
{
/**
* Run the migrations.
*
* @return void
*/
public function up()
{
Schema::table('produits', function(Blueprint $table) {
$table->dropColumn('couleur');
$table->integer('couleur_id')->unsigned()->after('description');
$table->foreign('couleur_id')->references('id')->on('couleurs');
});
}
/**
* Reverse the migrations.
*
* @return void
*/
public function down()
{
Schema::table('produits', function(Blueprint $table) {
$table->dropForeign('produits_couleur_id_foreign');
$table->dropColumn('couleur_id');
$table->string('couleur')->after('description');
});
}
}
Les principales fonctions de modification sont :
Ex :
$table->integer('couleur_id')->unsigned()->after('description');
Ex :
$table->dropColumn('couleur');
Ex :
$table->renameColumn('email', 'courriel');
Attention : pour ne pas perdre les données dans la BD, il est préférable que le fichier de migration ne fasse rien d'autre que le rename. On pourra faire d'autres opérations dans un autre fichier de migration.
Ex :
$table->string('prenom', 50)->change();
Le nom de la clé étrangère est monté sous le format tablesecondaire_cleetrangere_foreign.
Par exemple, pour détuire une contrainte dans la table produits pour le champ categorie_id qui pointe vers le champ id de la table categories :
$table->dropForeign('produits_categorie_id_foreign');
En cas de doute sur le nom de la contrainte, vous pouvez exporter la table et vérifier dans le script SQL généré.
Pour plus de détails : https://laravel.com/docs/master/migrations#columns
Remarquez que lorsque la méthode up() ajoute une contrainte d'intégrité référentielle, la méthode down() devra supprimer cette contrainte AVANT de supprimer la clé étrangère impliquée dans la relation.
Avant d'exécuter les fichiers de migration, surtout lors de la modification d'une table, il est conseillé de vérifier les lignes de code SQL qui seront générées :
php artisan migrate --pretend
Pour rendre les modifications effectives :
php artisan migrate
▼Publicité
