Je suis sur le point d'avoir mon projet prêt à démarrer. J'ai de grands projets pour après le lancement et la structure de la base de données va changer - de nouvelles colonnes dans les tables existantes ainsi que de nouvelles tables, et de nouvelles associations à des modèles existants et nouveaux.
Je n'ai pas encore touché aux migrations dans Sequelize, car je n'ai eu que des données de test que je ne crains pas d'effacer à chaque fois que la base de données change.
À cette fin, j'exécute actuellement sync force: true
lorsque mon application démarre, si j'ai changé les définitions de modèle. Cela supprime toutes les tables et les crée à partir de zéro. Je pourrais omettre l' force
option de ne créer que de nouvelles tables. Mais si ceux existants ont changé, cela n'est pas utile.
Donc, une fois que j'ajoute des migrations, comment les choses fonctionnent-elles? Évidemment, je ne veux pas que les tables existantes (contenant des données) soient effacées, c'est donc sync force: true
hors de question. Sur d'autres applications que j'ai aidé à développer (Laravel et autres frameworks) dans le cadre de la procédure de déploiement de l'application, nous exécutons la commande migrate pour exécuter toutes les migrations en attente. Mais dans ces applications, la toute première migration a une base de données squelette, avec la base de données dans l'état où elle était au début du développement - la première version alpha ou autre. Ainsi, même une instance de l'application en retard à la fête peut se mettre à niveau en une seule fois, en exécutant toutes les migrations dans l'ordre.
Comment générer une telle "première migration" dans Sequelize? Si je n'en ai pas, une nouvelle instance de l'application en aval de la ligne n'aura pas de base de données squelette sur laquelle exécuter les migrations, ou elle se synchronisera au début et rendra la base de données dans le nouvel état avec tous les nouvelles tables, etc., mais quand il essaie d'exécuter les migrations, elles n'auront aucun sens, car elles ont été écrites avec la base de données d'origine et chaque itération successive à l'esprit.
Ma réflexion: à chaque étape, la base de données initiale plus chaque migration en séquence doit être égale (plus ou moins de données) à la base de données générée lorsque sync force: true
est exécuté. En effet, les descriptions de modèle dans le code décrivent la structure de la base de données. Alors peut-être que s'il n'y a pas de table de migration, nous exécutons simplement la synchronisation et marquons toutes les migrations comme terminées, même si elles n'ont pas été exécutées. Est-ce ce que je dois faire (comment?), Ou Sequelize est-il censé le faire lui-même, ou est-ce que je suis en train d'aboyer le mauvais arbre? Et si je suis dans le bon domaine, il devrait sûrement y avoir un bon moyen de générer automatiquement la majeure partie d'une migration, étant donné les anciens modèles (par commit hash? Ou même chaque migration pourrait-elle être liée à un commit? Je concède que je pense dans un univers non portable centré sur git) et les nouveaux modèles. Il peut modifier la structure et générer les commandes nécessaires pour transformer la base de données d'ancienne en nouvelle, et inversement, puis le développeur peut entrer et apporter les modifications nécessaires (suppression / transition de données particulières, etc.).
Lorsque j'exécute le binaire sequelize avec la --init
commande, il me donne un répertoire de migrations vide. Quand je l'exécute, sequelize --migrate
cela me fait une table SequelizeMeta avec rien dedans, pas d'autres tables. Evidemment non, car ce binaire ne sait pas comment démarrer mon application et charger les modèles.
J'ai dû louper quelque chose.
TLDR: comment configurer mon application et ses migrations afin que diverses instances de l'application en direct puissent être mises à jour, ainsi qu'une toute nouvelle application sans base de données de départ héritée?
sync
pour le moment, l'idée est que les migrations "génèrent" la base de données entière, donc s'appuyer sur un squelette est en soi un problème. Le flux de travail Ruby on Rails, par exemple, utilise Migrations pour tout, et c'est assez génial une fois que vous vous y êtes habitué. Edit: Et oui, j'ai remarqué que cette question est assez ancienne, mais comme il n'y a jamais eu de réponse satisfaisante et que les gens peuvent venir ici pour chercher des conseils, j'ai pensé que je devrais contribuer.