La méthode de développement du framework Laravel est agile et itérative, et vous ne vous attendez pas à obtenir tout le code correct du premier coup. Au lieu de cela, nous écrivons du code, testons et interagissons avec nos utilisateurs finaux et affinons notre compréhension.
Pour le travail, nous avons besoin d'un ensemble de pratiques de soutien. Nous utilisons des outils de contrôle de version comme Subversion, GIT ou Mercurial pour stocker les fichiers de code source de l'application, ce qui nous permet d'annuler les erreurs et de suivre les modifications pendant le développement.
Mais lorsque les applications changent, il existe des domaines que nous ne pouvons pas gérer efficacement en utilisant uniquement le contrôle de version. Au fur et à mesure de notre développement, le schéma de base de données de l'application Laravel a continué d'évoluer : nous avons ajouté une table ici, renommé des colonnes là, supprimé des index, etc. Les modifications de la base de données sont effectuées en phase avec le code de l'application.
Vous avez besoin d'un moyen sophistiqué pour suivre les modifications du schéma de votre base de données. Il existe généralement plusieurs approches :
Lorsque vous travaillez au sein d'une équipe de développement, tout le monde doit savoir tout changement de schéma.
Lorsque vous déployez sur un serveur de production, vous devez disposer d'un moyen robuste pour mettre à niveau votre schéma de base de données.
Si vous travaillez sur plusieurs machines, vous devez synchroniser tous les schémas de base de données.
Garder le schéma de base de données synchronisé avec le code de l'application a toujours été un travail très fastidieux sans conventions et disciplines strictes à suivre pour les développeurs d'applications. Le développeur (ou l'administrateur de la base de données) apporte les modifications de schéma requises. Toutefois, si le code de l'application est restauré vers une version précédente, il est difficile d'annuler les modifications apportées au schéma de la base de données, ce qui entraîne une incohérence des informations sur la version de la base de données avec celles du code de l'application.
La migration est le moyen utilisé par Laravel pour vous aider à faire évoluer l'architecture des données de votre application sans vous obliger à supprimer ou à reconstruire la base de données à chaque fois que vous effectuez une modification. Aucune suppression ni reconstruction signifie que vous ne perdez pas de données à chaque fois que vous effectuez une modification. Le seul changement lorsque vous effectuez une migration consiste à déplacer le schéma de base de données d'une version à une autre, que ce soit vers l'avant ou vers l'arrière.
La migration Laravel vous offre un moyen de modifier le schéma de la base de données de manière itérative. Elle ne vous oblige pas à utiliser des opérations SQL, mais vous permet d'utiliser du code PHP. Le générateur de schéma Laravel nous permet de créer rapidement des tables de base de données et d'insérer des colonnes ou des index. Il utilise une syntaxe propre et expressive pour manipuler les bases de données. Vous pourriez penser que la migration Laravel est un contrôle de version de votre base de données.
En définissant une interface de niveau supérieur pour créer et maintenir des schémas de base de données, vous pouvez la définir de manière indépendante de la base de données. En utilisant PHP pour créer des tables, définir des colonnes et des index, écrire le schéma une fois et l'appliquer à n'importe quel backend de base de données pris en charge. Comme avantage supplémentaire, Laravel garde une trace des migrations qui ont été appliquées et de celles qui doivent encore l'être.
Une migration Laravel est simplement un fichier source PHP dans le répertoire app/database/migrations de votre application. Chaque fichier contient un ensemble de modifications apportées à la base de données sous-jacente. Les modifications apportées à la base de données sont effectuées dans le code PHP plutôt que dans le SQL spécifique à la base de données. Votre code de migration PHP est finalement converti en DDL qui correspond à votre base de données actuelle, ce qui facilite grandement le changement de plateforme de base de données. Étant donné que le code de migration est stocké dans son propre répertoire, il doit être inclus dans le contrôle de version comme tout autre code de projet. Les migrations Laravel sont exécutées explicitement à partir de la ligne de commande à l'aide des outils Artisan.
Dans les anciennes versions de Laravel, les fichiers migrés ont des noms plus simples, tels que 001_create_employees_table.php. Laravel 3 (Laravel 4.1 et identique) a apporté une nouvelle convention de dénomination dans laquelle la première partie du nom est passée d'un numéro de séquence à quelque chose de plus long, comme 2014_03_11_032903_create_employees_table.php. Le nom du fichier est au format AAAA_MM_JJ_HHMMSS_some_meaningful_name.php, ce qui signifie un horodatage UTC identifié suivi d'un nom de migration.
Les nouveaux noms plus larges permettent d'éviter les conflits de noms, et si vous êtes un développeur travaillant en équipe, vous pouvez vérifier vos propres migrations.
De plus, Laravel migre les horodatages des fichiers afin qu'ils puissent être exécutés séquentiellement. Les numéros d'horodatage sont essentiels aux migrations, car ils définissent quelle migration est appliquée dans l'ordre dans lequel les numéros de version de migration individuels sont appliqués.
Comme les scripts SQL, les migrations sont exécutées par le haut, ce qui nécessite l'exécution de ces fichiers. L'exécution séquentielle supprime la possibilité de tenter d'insérer des colonnes lorsque la table n'existe pas.
Bien que vous puissiez créer des fichiers de migration manuellement, il est plus facile (et moins sujet aux erreurs) d'utiliser les outils Artisan pour générer des scripts de migration. Vous pouvez modifier ces fichiers ultérieurement si nécessaire.
Utilisez les outils Artisan pour migrer vers la base de données. Laravel fournit un ensemble de tâches artisanales qui se résument à l'exécution d'un ensemble spécifique de migrations.
[Remarque]Vous pouvez exécuter la liste des artisans pour afficher la liste des tâches prises en charge par l'artisan . La plupart des tâches liées à la migration des données portent le préfixe migrate :.
Il n'y a que quelques tâches courantes que vous devez connaître :
migrate:install
La première tâche artisanale liée à la migration que vous pouvez utiliser est migrate:install. En interne, Laravel utilise des tables spéciales pour suivre quelles migrations ont été exécutées. Pour créer cette table, utilisez simplement l'outil de ligne de commande artisan :
$php artisan migrate:install
migrate
Vous exécuterez la tâche migrate pour mettre à jour fréquemment votre table. pour prendre en charge les dernières tables et colonnes que vous ajoutez à votre application. Dans sa forme la plus basique, il exécute uniquement la méthode up() sur toutes les migrations qui n'ont pas encore été exécutées. S'il n'y a pas de migration de ce type, elle se terminera. Il exécutera ces migrations en fonction de la date à laquelle elles ont été migrées.
migrate:rollback
Faites parfois des erreurs lors de l'écriture des migrations. Si vous avez déjà exécuté la migration, vous ne pouvez pas simplement la modifier et la réexécuter : Laravel suppose qu'il a déjà exécuté la migration, donc lorsque vous exécutez à nouveau artisan
migrer, ne fera rien. vous devez utiliser un artisan
migrate : rollback annule la migration, puis la modifie, puis exécute artisan
migrez pour exécuter la version correcte.
En général, modifier une migration existante n'est pas une bonne idée : cela nécessitera un travail supplémentaire pour vous et vos collègues, et ce sera un casse-tête si la migration des versions existantes est déjà en cours. sur les machines de production. Au lieu de cela, vous devez écrire une nouvelle migration pour effectuer les modifications requises.
[Note]artisan migrate:rollback supprimera la dernière application de migration. Laravel remonte à l'ensemble de "l'opération" de migration. Par conséquent, si la dernière commande de migration a exécuté 15 migrations, les 15 migrations seront toutes annulées. Veuillez noter que lorsque vous supprimez une colonne ou un tableau, les données seront perdues.
migrate:reset
Annuler toutes les migrations (toutes les tables et données seront supprimées)
migrate:refresh
la tâche artisanale migrate:refresh supprimera la base de données et la recréera et chargera le schéma actuel. Il s'agit d'un raccourci pratique pour exécuter une réinitialisation et réexécuter ensuite toutes les migrations.
migrate:make
artisan migrate:make commande indique
Laravel pour générer un squelette de fichier de migration (qui est en fait un
PHP) et stockez-le dans le dossier app/database/migrations. Vous pouvez ensuite éditer ce fichier pour étoffer vos définitions de table/index. Ensuite, artisan
Lorsque la commande migrate est exécutée, l'artisan interrogera ce fichier pour générer
Code réel pour SQL DDL.
Recommandations associées :
Comment connecter Laravel5 à sqlserver via freetds (code)
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
