¿Vale la pena usar sqlalchemy-migrate?

Tengo una aplicación web que usa sqlalchemy (dentro de Pylons). Necesito cambiar de manera eficiente el esquema para poder cambiar la versión de producción al menos sobre una base diaria, tal vez más, sin perder los datos.

He jugado un poco con sqlalchemy-migrate durante el fin de semana y diría que me causó una mala impresión. Primero creo que no puede ayudar con la migración entre dos motores de bases de datos ; eso es algo que probablemente se podría hacer con sqlalchemy solo. En segundo lugar los documentos no parecen estar al día. Tuve que cambiar algunas opciones de línea de comandos, como dar la ruta del repository a cada comando, esto podría ser un error de migración.

Pero lo peor es el comando “manage.py test “. No solo modifica realmente la base de datos (este punto está claramente indicado en la documentación, así que no puedo culpar a migrar), sino que mi primer script de migración acaba de hacer una migración de esquema estúpido, dejando a la db actualizada con un esquema diferente al original . Pero la “prueba de manage.py” acaba de responder algo así como

success ! 

Es decir, ni siquiera comprobó si el esquema se dejó en un estado coherente. Entonces , ¿vale la pena usar migrar? ¿Existe alguna ventaja en comparación con el método Do It Yourself asociado con las buenas prácticas propuesto por S.Lott ? ¿Existen alternativas a sqlalchemy-migrate que en realidad simplifique el proceso de migración o solo estoy tratando de usar migrar con un mal a priori (entonces, por favor, muéstrame por qué no es claramente superior a crear columnas CSV como se propone en el enlace anterior)?

¡Muchas gracias!

    Utilice Alambique en su lugar:

    http://pypi.python.org/pypi/alembic

    Gracias por los comentarios, editado para agregar algún razonamiento –

    Está desarrollado por el autor de SQLAlchemy, y es completamente nuevo y está bien soportado. No sé lo suficiente acerca de sqlalchemy-migrate para dar una buena comparación. Pero hice una lectura rápida a través de los documentos de Alembic claros y concisos, luego conseguí que mi propia migración autogenerada funcionara en muy poco tiempo.

    Autogeneración: no es su único modo de operación, pero si lo elige, Alembic leerá la configuración de sqlalchemy de su aplicación (por ejemplo, sus clases de modelo declarativo que configuran todas sus tablas, restricciones y asignaciones) y se compara con el estado actual actual de su base de datos, y generar un script de Python que represente el delta entre los dos. A continuación, pasa ese script al comando de actualización de Alembic y, a continuación, las diferencias se resuelven. Por lo general, se necesita una pequeña cantidad de edición del script de migración a mano, y eso es (a) solo la naturaleza de las migraciones, y (b) cualquier cosa que desee hacer de todos modos para asegurarse de que estaba completamente al tanto de los pasos exactos en que se realiza la migración. Va a actuar antes de ejecutarlo.

    Alembic también ofrece una capacidad similar a la de DVCS en la forma en que se realiza un seguimiento de sus migraciones. Hace que sea realmente fácil volver a cualquier estado anterior de su esquema de db.

    Alembic está fuera ( http://pypi.python.org/pypi/alembic ) y es mantenido por el autor de SQLAlchemy y dado el hecho de que el desarrollo de sqlalchemy-migrate se ve estancado, prácticamente sin compromiso este año ( http://code.google). com / p / sqlalchemy-migrate / source / list ), creo que ya no vale la pena usarlo, cambiaré mi proyecto actual a Alembic.

    Si aún se mantuviera en gran medida, estaría seguro de la capacidad del proyecto para mantener la sincronización con SQLAlchemy (lo que era el caso antes).

    Personalmente me encanta usarlo. Es increíble porque las nuevas instalaciones (dev, test, prod) pueden ser bootstrapped muy fácilmente. No solo eso, sino que proporciona un hogar para la aplicación a medida que crece y proporciona buenos puntos de entrada para aquellas migraciones que deben realizarse al pasar de una versión a otra de su aplicación. Algo debe realizar el cambio / etc en los servidores de desarrollo, prueba y producción.

    Es perfecto No Puedes dejar tu db en mal estado, pero es por eso que tienes versiones de dev / testing / production de las cosas.

    Personalmente lo uso para iniciar mis pruebas de unidad en pilones usando un db sqlite para ejecutar pruebas de unidad contra, pero usamos mysql en producción. Así que hay algunas ventajas de plataforma db cruz de su uso.