Je viens de commencer à utiliser South, et je suis 100% convaincu. C'est aussi l'un des rares logiciels à être encore en développement très actif.
South devrait être en mesure de gérer correctement les problèmes que vous avez décrits ci-dessus. Pour chaque changement dans la base de données, il crée un fichier qui a 2 méthodes "foward" et "backwards". Voici un exemple de migration générée automatiquement :
# > manage.py schemamigration issuetracker added-status-field --auto
# 0004_added-status-field.py
class Migration:
def forwards(self, orm):
# Adding field 'Issue.status'
db.add_column('issuetracker_issue', 'status', orm['issuetracker.issue:status'])
def backwards(self, orm):
# Deleting field 'Issue.status'
db.delete_column('issuetracker_issue', 'status')
Quelques-uns de ses avantages....
-
South vous permet de revenir à une migration spécifique si vous le souhaitez.
-
Si votre site de production est sur la migration 0002 et que votre commit SVN est sur 0004, South fera 0003 puis 0004 pour mettre à jour la base de données de production.
-
Si vous avez effectué les changements vous-même, vous pouvez demander à South d'exécuter une "fausse" migration. En temps normal, un système de migration se mettrait en colère, mais cette option permet d'avoir un contrôle flexible sur votre base de données.
manage.py migrate [appname] --fake
-
Si vous avez besoin de faire quelque chose de personnalisé, comme par exemple copier les données d'une colonne vers une autre colonne, comme les fichiers de migration sont juste des fichiers python, il est facile de modifier les fonctions avant/arrière.
-
Migrer vers South après avoir déjà déployé une application était plutôt facile. La dernière version 0.6 inclut d'ailleurs une commande pour cela.
manage.py convert_ to _south [appname]
-
Et bien sûr, comment oublier, ma fonction préférée est la génération automatique des fichiers de migration.
manage.py schemamigration [appname] [description] --auto
Gotchas
J'ai pensé que je devais ajouter quelques conseils pour les erreurs que j'ai commises lorsque j'ai commencé avec South. Tout n'est pas 100% intuitif.
-
Après avoir exécuté la commande convert_to_south sur votre base de données de développement, n'oubliez pas d'exécuter la commande suivante migrate --fake sur votre base de données de production, sinon South pensera qu'elle est périmée.
-
Si vous créez une nouvelle application, vous utilisez la fonction --initial drapeau
-
Arrêtez d'utiliser manage.py syncdb. Vraiment.
-
L'édition d'un modèle est un processus en 3 étapes --
1.) sauvegarder les modifications du modèle
2.) courir schemamigration --auto
3.) courir migrate pour valider les changements dans la base de données
Editer -- Pour clarifier les commentaires ci-dessous, South a été officiellement voté par les principaux contributeurs pour ne pas être inclus dans la version 1.2. Ceci était en partie dû au fait que l'auteur de South avait demandé à ce qu'il ne soit pas encore inclus. Malgré cela, South bénéficie d'un soutien important de la part de la communauté, et certains fabricants d'applications réutilisables commencent à inclure les migrations South dans leurs applications.
Edit #2 -- J'ai fait quelques mises à jour pour refléter la nouvelle structure de la commande manage.py de la version actuelle du tronc de South. La commande "startmigration" a été divisée en "schemamigration" et "datamigration" en fonction de ce que vous faites.
