Comment travailler avec les migrations

Question

j'utilise Laravel (j'ai ajouté RoR comme étiquette depuis que je sais que les migrations sont un peu semblables entre les deux) il y a quelques semaines et je luttais encore un peu pour s'y habituer à travailler avec les migrations. J'ai essayé de lire des documentations et des tutoriels (à la fois pour Laravel et d'autres frameworks qui les utilisent, comme Rails) et ils expliquent généralement comment les utiliser, mais je n'arrive toujours pas à comprendre comment travailler efficacement avec eux. Quelques questions que j'ai:

1. Si je crée une table dans une vue et plus tard décider d'ajouter quelques colonnes et peut-être déposer quelques autres, comment dois-je faire cela? Je comprends que la modification d'une migration existante n'est pas la bonne. Est-ce que j'ajoute une nouvelle migration qui ajoute les nouvelles colonnes et supprime les anciennes? Si oui, existe-t-il une convention de nommage pour eux, lors de la création d'une table appelée users, tous les tutoriels appellent habituellement la migration create_users, dois-je appeler cette migration update_users? Et si je voulais faire une autre mise à jour aux utilisateurs, j'aurais deux classes appelées Update_Users. En outre, le problème que j'ai avec cette approche est que j'ai l'impression de ne pas avoir un bon aperçu de la structure de la base de données, une colonne de tables pourrait être dispersée sur une douzaine de fichiers de migration.

2. Si je veux remplir mes tables avec des données de test, est-il préférable de le faire dans des migrations séparées, comme les graines dans Laravel 4?

3. Dois-je avoir un seul tableau dans chaque migration? Comme je le sais, dans ma migration create_users, je crée trois tables; users, roles et role_user, est-il préférable de les mettre dans des migrations séparées?

Answer 1

1. Modification d'une migration existante n'est pas la voie à suivre. Sinon, les modifications ne seront pas utilisées lors du déploiement sur votre système de production (les numéros de migration sont stockés dans la base de données elle-même pour éviter de les réexécuter). Ajoutez une autre migration pour effectuer les modifications. Il n'y a pas de véritable convention de dénomination pour mettre à jour/modifier les migrations en place. Alors nomme-le comme tu veux. Mais un nom propre indiquant pourquoi vous avez effectué la migration peut s'avérer utile (par exemple, AddCommentsToUsers).

2. Rails comporte un mécanisme d'ensemencement (voir Screencast). Vous devriez l'utiliser. Les migrations de données ont leurs inconvénients.

3. Je préfère une table par migration. Si la première création de la table est terminée mais que la seconde ne l'est pas, vous aurez des problèmes plus tard lorsque vous essayerez de relancer la migration (après avoir corrigé un problème avec).