Vaut-il la peine d'utiliser sqlalchemy-migrate?
J'ai une application web utilisant sqlalchemy (au sein de Pylons). Je dois changer efficacement le schéma pour pouvoir changer la version de production au moins quotidiennement, peut-être plus, sans perdre les données.
J'ai joué un peu avec sqlalchemy-migrate ce week-end et je dirais que ça m'a donné une mauvaise impression. Tout d'abord je pense que cela ne peut pas aider à la migration entre deux moteurs de bases de données ; c'est quelque chose qui pourrait probablement être fait avec sqlalchemy seul. Deuxièmement, les documents ne semblent pas à jour. J'ai dû changer certaines options de ligne de commande, comme donner le chemin du référentiel à chaque commande, cela pourrait être un bug de migration.
Mais le pire, c'est la commande "manage.py test ". Non seulement il modifie réellement la base de données (ce point est clairement indiqué dans la documentation, donc je ne peux pas blâmer la migration) mais mon premier script de migration vient d'être rendu clair migration de schéma stupide, laissant la base de données mise à niveau-rétrogradée avec un schéma différent de l'original . Mais le "test manage.py" a juste répondu à quelque chose comme
success !
Autrement dit, il n'a même pas vérifié si le schéma était laissé dans un état cohérent. Donc vaut-il la peine d'utiliser migrate? Y a-t-il un avantage par rapport à la méthode Do It Yourself associée aux bonnes pratiques comme proposé par S.Lott ? Existe-t-il des alternatives à sqlalchemy-migrate simplifiant le processus de migration ou est-ce que j'essaie simplement d'utiliser migrate avec un mauvais a a priori (alors s'il vous plaît, montrez-moi pourquoi ce n'est pas clairement supérieur à la création Colonnes CSV comme proposé dans le lien ci-dessus)?
Merci beaucoup!
Utilisez plutôt Alembic:
http://pypi.python.org/pypi/alembic
Merci pour les commentaires, modifiés pour ajouter du raisonnement -
Il est développé par l'auteur de SQLAlchemy, et il est tout nouveau et bien pris en charge. Je n'en sais pas assez sur sqlalchemy-migrate pour donner une bonne comparaison. Mais j'ai lu rapidement les documents clairs et concis d'Alembic, puis j'ai fait fonctionner ma propre migration générée automatiquement en très peu de temps.
Génération automatique: ce n'est pas son seul mode de fonctionnement, mais si vous le souhaitez, Alembic lira la configuration sqlalchemy de votre application (par exemple, vos classes de modèle déclaratif qui définissent toutes vos tables, contraintes et mappages) et les comparera à l'état actuel réel de votre base de données, et sortir un script Python qui représente le delta entre les deux. Vous passez ensuite ce script à la commande de mise à niveau d'Alembic et voilà, les différences sont résolues. Une petite quantité d'édition de la migration un script à la main est généralement nécessaire, et c'est (a) juste la nature des migrations, et (b) quelque chose que vous voulez faire de toute façon pour vous assurer que vous étiez pleinement conscient des étapes exactes que la migration va effectuer avant de l'exécuter .
Alembic apporte également une capacité de type DVCS à la façon dont vos migrations sont suivies. Il est très facile de revenir à n'importe quel état passé de votre schéma db.
Alembic étant sorti ( http://pypi.python.org/pypi/alembic ) et maintenu par l'auteur SQLAlchemy et étant donné que le développement sqlalchemy-migrate semble au point mort, avec pratiquement aucun engagement cette année (- http://code.google.com/p/sqlalchemy-migrate/source/list ), je pense que cela ne vaut plus la peine de l'utiliser , je vais passer mon projet actuel à Alembic.
S'il était encore fortement maintenu, je serais confiant sur la capacité du projet à rester synchronisé avec SQLAlchemy (ce qui était le cas auparavant).
Personnellement, j'adore l'utiliser. C'est génial car les nouvelles installations (dev, test, prod) peuvent être démarrées très facilement. Non seulement cela, mais il fournit une maison pour l'application à mesure qu'elle grandit et fournit de bons points d'entrée pour les migrations qui doivent avoir lieu lorsque vous passez d'une version à une autre de votre application. Quelque chose doit effectuer l'alter/etc sur les serveurs de développement, de test et de production.
C'est parfait? Nan. Vous pouvez laisser votre db dans un mauvais état, mais c'est pourquoi vous avez des versions dev/testing/production des choses.
Personnellement, je l'utilise pour bootstrap mes tests unitaires dans les pylônes en utilisant une base de données sqlite pour exécuter des tests unitaires contre, mais nous utilisons mysql en production. Il y a donc quelques avantages de la plate-forme cross db à l'utiliser.