vdegove
commented
10 months ago En réalité moi ce qui m’arrangerait, ça ne serait pas forcément de squasher les migrations, mais d’avoir le fichier apps/transport/priv/repo/structure.sql que tu génères avec mix ecto.dump en permanence généré et à jour. Ce fichier est précieux pour servir de documentation sur l’état actuel de la base de données dans ton éditeur de code, sans avoir à ouvrir un client SQL pour visualiser les indexs, les fonctions, les materialized views, etc.
En fait, squasher les migrations serait presque trompeur, puisque tu serais tenté de te reporter au dernier squash comme «documentation» alors que la structure réelle aurait déjà dérivée.
Je pense que le fonctionnement à la Rails me va bien : quand tu fais ta commande pour appliquer une migration (rails db:migrate ou mix ecto.migrate), ça met à jour automatiquement le fichier structure.sql (ou schema.rb dans le cas de Rails).
Bonus si tu peux aussi générer un PDF de modèle entité-association (ERD) au passage.
Est-ce que tu peux modifier le code pour que la tâche mix ecto.migrate appelle systématiquement mix ecto.dump ?
Actuellement on a 166 fichiers de migration (voir https://github.com/etalab/transport-site/tree/master/apps/transport/priv/repo/migrations).
Ça pose différents soucis, et aujourd'hui @vdegove s'est un peu galéré en lien avec ça (difficultés à comprendre pourquoi une erreur se produisait dans des tests, et au final c'était lié au "search vector").
Squasher les migrations de temps en temps donnerait un peu plus de clarté quand on débugge ce type de souci.
(mais il faudrait le faire de façon fiable et ne pas risquer d'oublier de dumper un élément).
Choses utiles en lien:
Un processus fiable est important, et si on peut le faire régulièrement facilement (automatiquement ça serait un plus).