Hibernación: hbm2ddl.auto=actualización en producción?

Lo hacemos en producción, aunque con una aplicación que no es de misión crítica y sin DBA altamente pagados en el personal. Es solo un proceso manual menos que está sujeto a errores humanos: la aplicación puede detectar la diferencia y hacer lo correcto, además de que presumiblemente lo ha probado en varios entornos de desarrollo y prueba.

Una advertencia: en un entorno agrupado, es posible que desee evitarlo porque pueden aparecer varias aplicaciones al mismo tiempo e intentar modificar el esquema que podría ser malo. O poner en algún mecanismo donde solo se permite una instancia para actualizar el esquema.

Hibernar Los creadores desalientan hacerlo en un entorno de producción en su libro "Java Persistence with Hibernate":

ADVERTENCIA: Hemos visto a usuarios de Hibernate intentando utilizar SchemaUpdate para actualizar automáticamente el esquema de una base de datos de producción. Esto puede terminar rápidamente en desastre y su DBA no lo permitirá.

Echa un vistazo a LiquiBase XML para mantener un registro de cambios de las actualizaciones. Nunca lo había usado hasta este año, pero descubrí que es muy fácil de aprender y hacer que el control de revisión de bases de datos/migración/gestión de cambios sea muy infalible. Trabajo en un proyecto Groovy/Grails, y Grails usa Hibernar debajo para todo su OR (llamado "GORM"). Utilizamos Liquibase para administrar todos los cambios de esquema SQL, lo que hacemos con bastante frecuencia a medida que nuestra aplicación evoluciona con nuevas características.

Básicamente, se mantiene un archivo XML de conjuntos de cambios que continúa agregando a medida que su aplicación evoluciona. Este archivo se guarda en git (o lo que sea que estés usando) con el resto de tu proyecto. Cuando se implementa su aplicación, Liquibase comprueba su tabla de registro de cambios en la base de datos a la que se está conectando para que sepa lo que ya se ha aplicado, luego simplemente aplica inteligentemente los conjuntos de cambios que aún no se han aplicado desde el archivo. Funciona absolutamente genial en la práctica, y si lo usa para todos sus cambios de esquema, entonces puede ser 100% seguro de que el código que usted compra e implementa siempre será capaz de conectarse a un esquema de base de datos totalmente compatible.

Lo impresionante es que puedo tomar una base de datos mysql totalmente en blanco en mi computadora portátil, encender la aplicación, y de inmediato el esquema está configurado para mí. También facilita la prueba de los cambios de esquema aplicándolos primero a una base de datos local-dev o staging.

La forma más fácil de comenzar con ella probablemente sería tomar su base de datos existente y luego usar Liquibase para generar una línea de base inicial.archivo xml. Luego, en el futuro, puede agregarlo y dejar que liquibase se encargue de administrar los cambios de esquema.

Http://www.liquibase.org/

Votaría no. Hibernate no parece entender cuando los tipos de datos de las columnas han cambiado. Ejemplos (usando MySQL):

String with @Column(length=50)  ==> varchar(50)
changed to
String with @Column(length=100) ==> still varchar(50), not changed to varchar(100)

@Temporal(TemporalType.TIMESTAMP,TIME,DATE) will not update the DB columns if changed

Probablemente también hay otros ejemplos, como empujar la longitud de una columna de cadena por encima de 255 y ver que se convierte en texto, texto medio, etc etc.

Concedido, no creo que realmente haya una manera de "convertir tipos de datos" sin crear una nueva columna, copiar los datos y eliminar la columna anterior. Pero en el momento en que su base de datos tiene columnas que no reflejan el mapeo de hibernación actual que estás viviendo muy peligrosamente...

Flyway es una buena opción para lidiar con este problema:

Http://flywaydb.org

Hibernate tiene que poner el descargo de responsabilidad sobre no usar actualizaciones automáticas en prod para cubrirse a sí mismos cuando las personas que no saben lo que están haciendo lo utilizan en situaciones en las que no debe ser utilizado.

Concedido las situaciones en las que no debe ser utilizado en gran medida superan en número a los que está bien.

Lo he usado durante años en muchos proyectos diferentes y nunca he tenido un solo problema. Esa no es una respuesta patética, y no es codificación vaquera. Es un hecho histórico.

Una persona quien dice "nunca lo hagas en producción" está pensando en un conjunto específico de despliegues de producción, es decir, aquellos con los que está familiarizado (su empresa, su industria, etc.).

El universo de los "despliegues de producción" es vasto y variado.

Un desarrollador experimentado de Hibernación sabe exactamente lo que DDL va a resultar de una configuración de asignación dada. Mientras pruebe y valide que lo que espera termina en el DDL (en dev, qa, staging, etc.), está bien.

Cuando son la adición de un montón de características, las actualizaciones automáticas de esquema puede ser un ahorro de tiempo real.

La lista de cosas que las actualizaciones automáticas no manejarán es interminable, pero algunos ejemplos son la migración de datos, la adición de columnas no anulables, los cambios de nombre de columna, etc., etc.

También debe tener cuidado en entornos agrupados.

Pero de nuevo, si supieras todas estas cosas, no estarías haciendo esta pregunta. Hmm . . . OK, si usted está haciendo esta pregunta, usted debe esperar hasta que tenga mucha experiencia con las actualizaciones de Hibernate y auto schema antes de pensar en usarlo en prod.

Como expliqué en este artículo, no es una buena idea usar hbm2ddl.auto en producción.

La única forma de administrar el esquema de base de datos es usar scripts de migración incremental porque:

• los scripts residirán en VCS a lo largo de su base de código. Cuando compras una rama, recreas todo el esquema desde cero.
• los scripts incrementales se pueden probar en un servidor QA antes de aplicarse en producción
• no hay necesidad de intervención manual dado que los scripts pueden ser ejecutados por Flyway, por lo tanto reduce la posibilidad de error humano asociado con la ejecución manual de scripts.

Incluso la Guía de Usuario de Hibernación le aconseja evitar el uso de la herramienta hbm2ddl para entornos de producción.

Lo hacemos en un proyecto en producción desde hace meses y nunca hemos tenido un problema hasta ahora. Tenga en cuenta los 2 ingredientes necesarios para esta receta:

1. Diseñe su modelo de objetos con un enfoque de compatibilidad hacia atrás, es decir, desaprovechar objetos y atributos en lugar de eliminarlos/alterarlos. Esto significa que si necesita cambiar el nombre de un objeto o atributo, deje el antiguo como está, agregue el nuevo y escriba algún tipo de script de migración. Si usted necesita para cambiar una asociación entre objetos, si ya está en producción, esto significa que su diseño estaba equivocado en primer lugar, así que intente pensar en una nueva forma de expresar la nueva relación, sin afectar los datos antiguos.

2. Siempre copia de seguridad la base de datos antes de la implementación.

Mi sensación es-después de leer este post-que el 90% de las personas que participan en esta discusión están horrorizadas solo con la idea de usar automatizaciones como esta en un entorno de producción. Algunos lanzan la pelota al DBA. Sin embargo, tómese un momento para considerar que no todos los entornos de producción proporcionarán un DBA y no muchos equipos de desarrollo pueden permitirse uno (al menos para proyectos de tamaño mediano). Así que, si estamos hablando de equipos donde todo el mundo tiene que hacer todo, la pelota está en ellos.

En este caso, ¿por qué no tratar de tener lo mejor de ambos mundos? Herramientas como esta están aquí para dar una mano, que-con un diseño y un plan cuidadosos - puede ayudar en muchas situaciones. Y créanme, los administradores pueden inicialmente ser difíciles de convencer, pero si saben que la pelota no está en sus manos, les encantará.

Personalmente, nunca volvería a escribir scripts a mano para extender cualquier tipo de esquema, pero esa es solo mi opinión. Y después de comenzar a adoptar bases de datos sin esquema NoSQL recientemente, puedo ver que más que pronto, todas estas operaciones basadas en esquemas pertenecerán al pasado, por lo que será mejor que comience a cambiar su perspectiva y mirar hacia adelante.

No me arriesgaría porque podría terminar perdiendo datos que deberían haberse conservado. hbm2ddl.auto = update es puramente una manera fácil de mantener su base de datos de desarrollo actualizada.

• En mi caso (Hibernate 3.5.2, Postgresql, Ubuntu), establecer hibernate.hbm2ddl.auto=update solo creó nuevas tablas y creó nuevas columnas en tablas ya existentes.

• No soltaba tablas, ni columnas, ni alteraba columnas. Se puede llamar una opción segura, pero algo como hibernate.hbm2ddl.auto=create_tables add_columns sería más claro.

No, nunca lo hagas. Hibernate no gestiona la migración de datos. Sí, hará que su esquema se vea correctamente, pero no garantiza que los datos de producción valiosos no se pierdan en el proceso.

No Es seguro, no se recomienda, pero es posible.

Tengo experiencia en una aplicación usando la opción de actualización automática en producción.

Bueno, los principales problemas y riesgos encontrados en esta solución son:

• Desplegar en la base de datos incorrecta. Si comete el error de ejecutar el servidor de aplicaciones con una versión antigua de la aplicación (EAR/WAR/etc) en la base de datos incorrecta... Tendrá muchas columnas, tablas, claves foráneas y errores nuevos. El mismo problema puede ocurrir con un simple error en el archivo de origen de datos, (copiar/pegar el archivo y se olvidó de cambiar la base de datos). En resumen, la situación puede ser un desastre en su base de datos.
• El servidor de aplicaciones tarda demasiado en arrancar. Esto ocurre porque el Hibernate intenta encontrar todas las tablas/columnas / etc creadas cada vez que inicie la aplicación. Él hace esto para saber qué (tabla, columna, etc.) necesita ser creado. Este problema solo empeorará.
• Herramientas de base de datos es casi imposible de usar . Para crear scripts para la base de datos, debe pensar en lo que creará la actualización automática después de iniciar el servidor de aplicaciones. Si necesita llenar una nueva columna (por ejemplo) con algunos datos, debe iniciar el servidor de aplicaciones, esperar a Hibernar creta la nueva columna y ejecutar el script SQL después de eso. Herramientas como Flyway es casi imposible de usar con la actualización automática habilitada.
• Los cambios en la base de datos no están centralizados. Con la posibilidad de la Hibernación crear las tablas y todo lo demás, es difícil ver los cambios en la base de datos en cada versión de la aplicación, porque la mayoría de ellos son automáticamente.
• Fomenta la basura en la base de datos. Debido a la facilidad de la actualización automática, existe la posibilidad de que tu equipo descuide eliminar columnas y tablas antiguas.
• Desastre inminente . El riesgo inminente de que ocurra algún desastre en la producción (como algunas personas mencionadas en otras respuestas). Incluso con una aplicación en ejecución y actualizable durante años, no creo que sea segura. Nunca me sentí segura.

Por lo tanto, no recomendaré usar la actualización automática en producción.

Si realmente quieres usar la actualización automática en producción, te recomiendo:

• redes Separadas. Su entorno de prueba no puede acceder al entorno homolog. Esto ayuda a evitar que una implementación que se suponía debía estar en el entorno de prueba cambie la base de datos de homologación.
• Gestionar orden de los scripts . Debe organizar los scripts para que se ejecuten antes de la implementación (cambio de tabla de estructura, tabla/columnas de eliminación) y el script después de la implementación (información de relleno para las nuevas columnas/tablas).

Y, a diferencia de las otras publicaciones, no creo que la actualización automática habilitada esté relacionada con DBA "muy bien pagados" (como se mencionó en otras publicaciones)... Los DBA tienen cosas más importantes que hacer que escribir sentencias SQL para crear / cambiar / eliminar tablas y columnas. Estos simples todos los días las tareas pueden ser realizadas y automatizadas por los desarrolladores y solo se pasan para que el equipo de DBA las revise, sin necesidad de Hibernar y DBA "muy bien pagados" para escribirlas.

• Por lo general, las aplicaciones empresariales en organizaciones grandes se ejecutan con privilegios reducidos.

• El nombre de usuario de la base de datos puede no tener el privilegio DDL para agregar columnas que hbm2ddl.auto=update requiere.

Estoy de acuerdo con Vladimir. Los administradores de mi empresa definitivamente no apreciarían si siquiera sugeriera un curso de este tipo.

Además, crear un script SQL en lugar de confiar ciegamente en Hibernate le da la oportunidad de eliminar los campos que ya no están en uso. Hibernar no hace eso.

Y encuentro que comparar el esquema de producción con el nuevo esquema le da una idea aún mejor de lo que cambió en el modelo de datos. Ya sabes, por supuesto, porque lo hiciste, pero ahora ves todos los cambios de una sola vez. Incluso los que te hacen decir " ¿Qué diablos?!".

Hay herramientas que pueden hacer un delta de esquema para usted, por lo que ni siquiera es un trabajo duro. Y entonces sabes exactamente lo que va a pasar.

El esquema de las aplicaciones puede evolucionar con el tiempo; si tiene varias instalaciones, que pueden estar en versiones diferentes, debe tener alguna manera de asegurarse de que su aplicación, algún tipo de herramienta o script sea capaz de migrar esquemas y datos de una versión paso a paso a cualquiera siguiente.

Tener toda su persistencia en asignaciones de hibernación (o anotaciones) es una muy buena manera de mantener la evolución del esquema bajo control.

Debe tener en cuenta que la evolución del esquema tiene varios aspectos que deben considerarse:

1. Evolución del esquema de base de datos en agregar más columnas y tablas

2. Caída de viejas columnas, tablas y relaciones

3. Rellenar nuevas columnas con valores predeterminados

Las herramientas de hibernación son importantes en particular en caso de que (como en mi experiencia) tenga diferentes versiones de la misma aplicación en muchos tipos diferentes de bases de datos.

El punto 3 es muy sensible en caso de que esté usando Hibernación, como en caso de introducir una nueva propiedad con valor booleano o una numérica, if Hibernate encontrará cualquier valor nulo en dichas columnas, if generará una excepción.

Entonces, lo que haría es: de hecho, use la capacidad de Hibernate tools de actualización de esquemas, pero debe agregar junto a ella algunos datos y devolución de llamada de mantenimiento de esquemas, como para rellenar los valores predeterminados, eliminar las columnas que ya no se usan y similares. De esta manera obtendrá las ventajas (scripts de actualización de esquemas independientes de la base de datos y evitar codificación duplicada de las actualizaciones, en persistence y en scripts) pero también cubre todos los aspectos de la operación.

Así que, por ejemplo, si una actualización de versión consiste simplemente en agregar una propiedad con valor varchar (por lo tanto, columna), que puede ser null por defecto, con la actualización automática habrá terminado. Cuando sea necesaria una mayor complejidad, será necesario trabajar más.

Esto supone que la aplicación cuando se actualiza es capaz de actualizar su esquema( se puede hacer), lo que también significa que debe tener los derechos de usuario para hacerlo en el esquema. Si la política del cliente evita esto (probablemente caso Lizard Brain), tendrá que proporcionar los scripts específicos de la base de datos.