Actualmente usando Django "Evolution", ¿es "Sur" mejor y vale la pena cambiar?

django-south django-evolution

Question

Actualmente estoy usando las evoluciones de Django para gestionar las evoluciones de la base de datos de mi producto. No es perfecto, pero he aprendido a vivir con sus defectos. Por ejemplo, siempre tengo que copiar mi base de datos de producción para probar antes de mover un nuevo esquema porque el comando "evolucionar" no siempre puede evolucionar una base de datos que se modificó en varias migraciones pequeñas (en la prueba hice A-> B-> C, pero A-> C no evolucionará correctamente.)

¿Solucionará South todos esos problemas? ¿Vale la pena el esfuerzo de aprender una nueva herramienta?

Answer 1

Empecé a usar South, y estoy 100% vendido en él. También es uno de los pocos que aún se encuentra en desarrollo muy activo.

South debería ser capaz de manejar adecuadamente los problemas que describió anteriormente. Para cada cambio a la base de datos, crea un archivo que tiene 2 métodos "adelante" y "hacia atrás". Aquí hay una muestra de migración generada automáticamente:

# > 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'')

Un par de cosas buenas sobre eso ...

• South le permite retroceder a una migración específica # si lo desea

• Si su sitio de producción está en la migración 0002 y su confirmación SVN está en 0004, South hará 0003 luego 0004 para acelerar la producción de db.

• Si ha realizado los cambios usted mismo, puede decirle a South que ejecute una migración "falsa". Normalmente, un sistema de migración lanzaría un ataque de hissy, pero esto hace que sea realmente fácil tener un control flexible sobre su db.

  manage.py migrate [appname] --fake

• Si necesita que ocurra algo personalizado, como copiar los datos en una columna a otra columna, porque los archivos de migración son solo archivos de Python, es fácil modificar las funciones hacia adelante / hacia atrás.

• Migrar a South luego de haber desplegado una aplicación fue bastante fácil. La última versión 0.6 incluye un comando para ello en realidad.

  manage.py convert_ to _south [appname]

• Y, por supuesto, ¿cómo podría olvidarlo? Mi característica favorita es la generación automática de archivos de migración

  manage.py schemamigration [appname] [description] --auto

Gotchas

Pensé que debería agregar algunos consejos sobre los errores que cometí al comenzar con South. No todo es 100% intuitivo.

• Después de ejecutar el comando convert_to_south en su base de datos de desarrollo, no olvide ejecutar migrate --fake en su base de datos de producción, de lo contrario, South migrate --fake que está desactualizado.

• Si está creando una nueva aplicación, usa la bandera --initial

• Deja de usar manage.py syncdb. De Verdad.

• Editar un modelo es un proceso de 3 pasos:

  1.) guardar los cambios del modelo

  2.) ejecutar schemamigration --auto

  3.) ejecutar migrate para realmente comprometer los cambios a la base de datos

Editar: para aclarar los comentarios a continuación, South fue oficialmente votado por los contribuyentes principales para que no se incluya con la versión 1.2. Esto se debió en parte a que el autor de South había solicitado que aún no se incluyera. Aún así, hay mucho apoyo de la comunidad para South, y algunos fabricantes de aplicaciones reutilizables están comenzando a incluir las migraciones del Sur con su aplicación.

Editar # 2: realicé algunas actualizaciones para reflejar la nueva estructura de comando manage.py a partir de la versión troncal actual de South. "startmigration" se ha dividido en "schemamigration" y "datamigration" dependiendo de lo que esté haciendo.