¿Las migraciones de Doctrine se pueden usar en aplicaciones de producción?

Question

Como previously discussed, estamos desarrollando una aplicación PHP en torno a Zend Framework que necesita actualizar su base de datos con bastante frecuencia y de forma cruzada a medida que avanzamos en las etapas de desarrollo.

Actualmente estamos utilizando Rails Migrations para esto, aunque estando ellos en Ruby (y Ruby en Windows siendo el desastre), estamos teniendo dificultades para distribuir migraciones a clientes que tienen instalaciones basadas en Windows. Incluso en Linux, el acceso a bases de datos MS SQL y Oracle con Ruby es un problema.

Queremos reemplazar Rails Migrations con Doctrine, pero se sienten muy inmaduros. No hay mucha documentación y hay algunos errores en el seguimiento de que una señal de alerta sobre el estado del proyecto, tales como:

• renameColumn() drops the column
• Data loss on table renaming

Si examina el código, esos dos en realidad bajan la tabla o columna original y lo vuelven a crear sin guardar los datos. Este es un factor decisivo que me hace pensar que nadie realmente usa Doctrine Migrations.

Además, leí en la documentación que las migraciones utilizan la numeración secuencial (versión 1, versión 2, etc.) haciéndolos completamente inadecuado para el desarrollo de muchas ramas, pero entonces el DoctrineMigrationsBundle Symfony documentation utiliza versiones basadas en fechas que hacen tiene sentido.

¿Alguien tiene experiencia en el mundo real con la herramienta o conoce el estado de desarrollo de la misma?

Answer 1

Para ser sincero, las migraciones de Doctrine son mejores que la mayoría de las ofertas que existen; sin embargo, son un poco inmaduros y es difícil encontrar documentación. Dicho esto, si se mantiene en un ámbito limitado, funcionan muy bien.

Además, con cualquier herramienta de migración, simplemente debe tener cuidado y no esperar que proporcione magia.

Dicho esto, no existe una herramienta multiplataforma que sea tan completa y probada en la naturaleza como la liquibase. Además, ninguna otra herramienta que conozca incluye una herramienta de documentación de base de datos.

La siguiente charla sobre Liquibase que debe proporcionar suficiente información para ayudarle a empezar:

http://slidedecks.wilmoore.com/2012-confoo/painless-version-controlled-database-refactoring

Answer 2

Si usted está buscando en Doctrina 2, entonces, posiblemente, puede ser un poco inmaduro, especialmente si Queremos usar solo la biblioteca de Migraciones. Desde mi experiencia con él como una biblioteca independiente, y no como parte de Doctrine2 ORM, no es un producto sólido. Para su crédito, sigue siendo Alpha, y Doctrine como ORM completo es una biblioteca bastante dulce (y las migraciones funcionan muy bien como parte de ella).

He utilizado Doctrine 1.X como un ORM completo y la migración en muchos entornos de producción, y funciona muy bien.

Answer 3

Hemos analizado más acerca de Migraciones de Doctrine y hemos obtenido algunos datos sobre su funcionamiento interno (y también hemos actualizado los errores vinculados en el OP).

El problema principal es que Doctrine tiene un enfoque fundamentalmente diferente de las migraciones.Construye un modelo abstracto a partir de su esquema DB y luego le permite modificar ese modelo. Estas modificaciones no tienen ningún impacto en el DB subyacente, pero Doctrine las usa para inferir los cambios reales que deben realizarse en el DB.

Es como diff para bases de datos. Esto tiene algunas consecuencias muy desagradables. Por ejemplo, si cambia el nombre de una columna en la base de datos de la operación en el modelo se parece a:

public function renameColumn($oldColumnName, $newColumnName) 
{ 
    $column = $this->getColumn($oldColumnName); 
    $this->dropColumn($oldColumnName); 

    $column->_setName($newColumnName); 
    return $this; 
} 

Si utiliza esta función y luego tener Doctrina aplica la migración, se busca entonces las diferencias entre la vieja y la el nuevo esquema (columnas faltantes, columnas agregadas y los tipos de esos) e inferir si es necesario cambiar el nombre de una columna existente o descartar la anterior y crear una nueva. Esto significa que Doctrine cree que renombrar una columna es en realidad lo mismo que dejarla caer y volver a crearla, y por lo tanto es muy tonto al respecto.

• Si cambia el nombre de una sola columna y no cambia nada más, emitirá un comando "cambiar el nombre" en el DBMS.
• Si cambia el nombre de una columna y cambia su tipo (por ejemplo, varchar (80) a varchar (100), la soltará y la creará de nuevo.
• Si cambia el nombre de 2 columnas y no cambia nada, se asuste y soltar a los dos y les recreado (el algoritmo diff es que rudimentaria)

creo que es un mal enfoque de las migraciones de base de datos, ya que no funciona correctamente. el objetivo de esta herramienta es mantener los datos a través de las migraciones y esto falla ese requisito básico.

Dicho esto, lo estamos usando de todos modos porque simplemente no hay nada mejor. Hemos añadido deliberat Mensajes de falla en las operaciones no confiables para evitar que los desarrolladores se vean atrapados en las numerosas trampas.