Trataré de actualizar este "tema" con mis hallazgos después de probar rápidamente el complemento de Juan y todos los demás mencionados excepto el de CakeDC ... ya que no lo hago t tiene la aplicación relevante actualizada para CakePHP 1.3 y ese plugin de migración requiere 1.3
Debo notar que los comentarios sobre fallas y complementos que no funcionan para mí deben leerse principalmente como "no adecuados para MIS necesidades" o "errores que he cometido" al intentarlos ". Hasta cierto punto, algunos podrían leer tales comentarios como una petición de revisión en la documentación. No insinúo que los complementos probados son intrínsecamente defectuosos, defectuosos o rotos. Estoy seguro de que todos ellos trabajan en las circunstancias correctas y para los flujos de trabajo correctos.
CakePHP esquema Shell
tiene el concepto simple que me gusta. El esquema está vinculado al código y el SCM utilizado para gestionar sus revisiones.
Funciona muy bien a un punto.Ese punto es:
No aparece adecuado para la implementación automatizada. Es decir. El comando de actualización solo puede modificar tablas, no manejar tablas nuevas o eliminadas. Esos son manejados por sus propios comandos de shell haciendo complicada la implementación del estilo Cap. También ejecutar actualizaciones con una nueva tabla producirá errores cuando la secuencia de comandos intente "alterar" la tabla no existente. Estoy seguro de que si esto es intencionado o un problema que estoy teniendo. (He pedido en el grupo de Google sin respuesta aún)
migraciones CakeDC
- sonido como tomaron el Shell de esquema y "fija" la misma. Los documentos explican un procedimiento un poco más complicado (al menos para explicarlo) pero podría funcionar como yo quisiera.
YAML, joelmoss y las migraciones de juan
Estos comparten el concepto de carriles de ficheros versionados y "Upping" y "derribo" entre ellos. Me gusta menos ya que no puedo ver una situación para mis proyectos cuando la migración de un esquema se actualizaría o retrotraería sin hacer lo mismo con el código fuente. También puedo vivir sin la capacidad de migrar datos existentes en un script de migración, ya que lo preveo como algo muy raro para mí.
Estos todos esperan que yo no toco la base de datos a través de cualquier medio distinto de scripts de migración. No puedo abrir mi MySql-GUI favorita y jugar hasta que esté contento y luego generar un "diff" a través de estos scripts. (Al menos no he encontrado formas documentadas de hacerlo durante mis breves pruebas). Tengo que escribir manualmente los cambios en los archivos YAML o php. Como estoy empezando en un proyecto existente con alrededor de 30 tablas, no me agrada la idea de volver a escribir ese esquema manualmente. Pero algunos de estos complementos no crearon un buen archivo de punto de partida con todas mis tablas. Probablemente esto también se debió a mis breves pruebas y/o incapacidad para encontrar documentación para tal característica. No profundicé en el código fuente de la mayoría de estos.
Mi siguiente paso parece ser la actualización de mi proyecto de CakePHP 1.3 y dar el último plug-in de un intento. Pero no sé cuándo tendré tiempo para eso. (Es decir, no cualquier persona contener la respiración)
Si cree que he entendido mal la forma en cualquiera de estos plugins funcionan y pueden ofrecer éxitos en cuanto a cómo hacer que funcionen para mí. Estaría feliz por la respuesta de un comentario.
+1, pregunta interesante –
Ignorando la documentación y leyendo la fuente, he descubierto cómo hacer que Schema Shell haga prácticamente todo lo que necesito. Descubrí que -f no "fuerza" a generar "para crear un nuevo esquema". Se usa "Forzar la generación de todas las tablas en el esquema ...". Pero no solo eso, y esto no está en los documentos: también se puede usar para obligar a la actualización a ignorar las clases de modelo de la misma manera que a generar y, por lo tanto, actualizar un esquema generado con la opción. –
@Matin Westin: ¿por qué no aportar esas ideas a la wiki de documentación? – stevenf