¿Cómo manejo las evoluciones de la base de datos cuando estoy usando JPA?

Question

Aprendí a jugar siguiendo el tutorial en su sitio web para construir un pequeño motor de blogs.

Utiliza JPA y en su bootstrap llama a Fixtures.Deletemodels(), (o algo por el estilo).

Básicamente nukes todas las tablas cada vez que se ejecuta y pierdo todos los datos.

Implementé un sistema de producción como (sin la instrucción nuke).

Ahora tengo que implementar una gran actualización para el sistema de producción. Muchas clases han cambiado, se han agregado y se han eliminado. En mis pruebas locales, sin anular las tablas en cada ejecución, encontré problemas de sincronización. Cuando intentaba escribir o leer desde tablas el juego arrojaba errores. Abrí mysql y, efectivamente, las tablas solo se habían modificado parcialmente y se habían modificado incorrectamente en algunos casos. Incluso si tengo el modo DDL configurado para "crear" en mi configuración, JPA parece no poder "resolver" cómo conciliar los cambios y modificar mi esquema en consecuencia.

Así que tengo que poner de nuevo en la declaración de arranque que nukes todas mis tablas.

Así que comencé a investigar las evoluciones de la base de datos dentro de Play y leí un artículo en el sitio web de play framework sobre las evoluciones de la base de datos. El artículo hablaba sobre scripts de versiones, pero decía: "Si trabajas con JPA, Hibernate puede manejar las evoluciones de la base de datos automáticamente. Las evoluciones son útiles si no usas JPA".

Entonces, si se supone que JPA se está ocupando de esto por mí, ¿cómo implemento grandes actualizaciones en una gran aplicación Play? Hasta ahora, JPA no ha podido hacer que el esquema cambie correctamente y la aplicación generará errores. No estoy interesado en perder todos mis datos, por lo que la corrección del dev "Fixtures.deleteModels()" no se puede usar realmente en prod.

Gracias de antemano, Josh

Answer 1

No, JPA no debería ocuparse de eso. No es una herramienta mágica. Si decide renombrar la tabla "cliente" a "cliente", la columna "calle" a "línea 1" y para cambiar los valores de la columna de tipo de cliente de 1, 2, 3 a "bronce", "plata", " oro ", no hay forma de que JPA lea en su mente y calcule todos los cambios para hacer automágicamente.

Para migrar de un esquema a otro, utiliza las mismas herramientas que si no usara las secuencias de comandos JPA: SQL o herramientas de migración de datos y esquemas más avanzados, o incluso el código JDBC de migración personalizada.

Answer 2

hay una propiedad llamada hbm2ddl.auto=update que actualizar el esquema. CORRECTAMENTE sugiero no utilizar esta configuración en producción, ya que presenta un nuevo nivel de problemas si algo sale mal. Sin embargo, está perfectamente bien para el desarrollo.

Answer 3

Eche un vistazo a flyway. Puede desencadenar migraciones de bases de datos desde su código o maven.

Answer 4

Cuando se inicia un contenedor JPA (por ejemplo, EclipseLink o cualquier otro), espera encontrar una base de datos que coincida con las clases @Entity que ha definido en su código. Si la base de datos ya se ha migrado, todo funcionará sin problemas; de lo contrario: probablemente fallará.

Por lo tanto, resumiendo, debe realizar migraciones de bases de datos (o evoluciones, si lo prefiere) antes de se inicia el contenedor JPA. Aparentemente, Play realiza las migraciones por ti antes de que Play inicie el administrador de la base de datos que configuraste.Entonces, en teoría, independientemente del ORM que esté utilizando, Play decide cuándo es el momento para que el ORM comience su trabajo. Entonces, conceptualmente debería funcionar.

Para una buena presentación sobre este tema, por favor, eche un vistazo en el segundo video en: http://flywaydb.org/documentation/videos.html