Par Valentin Brosseau / @c4software
Vous partiez de zéro : migration → table → modèle.
Question : et si la base de données existe déjà ?
On inverse donc : la base d'abord, les modèles ensuite.
$fillable.$order->customer->contactFirstNamePas de requête SQL écrite… mais elle a bien lieu.
public function customer()
{
return $this->belongsTo(Customer::class, 'customerNumber');
}$order->customer appelle cette méthode, qui génère la requête.
Ce code est dans la documentation, pas dans votre imagination.
Votre base a 20 tables.
Vous écrivez les 20 modèles et toutes leurs relations à la main ?
Un plugin lit la structure de la base (colonnes, clés étrangères) et écrit les modèles pour vous :
php artisan code:modelsQuelques secondes, tous les modèles, relations comprises.
Le générateur ne devine que si vos tables respectent les conventions :
customers).category_customer).Sinon ? Les relations s'écrivent à la main.
customers ← category_customer → categoriesUn client a plusieurs catégories, une catégorie a plusieurs clients.
La table du milieu s'appelle une table pivot.
$customer->categories()->attach([1, 2]); // Ajoute
$customer->categories()->sync([3, 4]); // Remplace tout
$customer->categories()->detach(1); // RetireÀ votre avis, lequel est le plus « dangereux » ?
Il supprime les relations existantes avant d'ajouter les nouvelles.
Parfait pour un formulaire d'édition… à éviter pour un simple ajout.
Order::paginate(10);{{ $orders->links() }}Deux lignes, et Laravel gère pages, liens et compteurs. Le framework, encore.
code:models), relations comprises.attach / sync / detach pour les tables pivot.paginate() + links() : la pagination en deux lignes.Place au TP 🚀