He estado mirando brevemente JPA recientemente, y me preguntaba cuál es el problema con las migraciones de esquemas de bases de datos y estar alineado con las clases que ha creado.¿Soporte para migraciones de esquema con JPA?
¿Hay soporte en JPA para esto? Utilidades? ¿Mejores prácticas?
¡Salud!
Si configura el generateDdl en Hibernate (si es la implementación subyacente), genera el esquema de la base de datos de acuerdo con su dialecto actual. Entonces, después de cambiar el dialecto, generará automáticamente la base de datos.
Otros proveedores de JPA pueden tener diferentes propiedades para esto.
Esto es correcto, pero no resuelve el problema de la migración de esquema. – HDave
@HDave - al contrario. El esquema se replica en la nueva base de datos, reflejando el modelo de datos actual. – Bozho
Por migración de esquema, creo que el OP significa tener scripts que pueden tomar una base de datos existente con datos y ponerla al día con las nuevas entidades/esquema. A menudo esto implica un estudio cuidadoso de los cambios de esquema y en algún momento la descarga/recarga de datos para poder cambiar los FK, los PK se pueden dividir, etc. Hibernate puede generar un script para crear un nuevo esquema. Hibernate también puede generar un script para modificar un esquema antiguo para convertirlo en un nuevo esquema, pero asume que la base de datos no tiene datos, y aun así, entiendo que rara vez se usa esa capacidad debido a "problemas". – HDave
La respuesta corta es no.
Si cambia sus granos, tendrá que migrar el esquema existente a mano. Por lo tanto, para migraciones de bases de datos de estilo de Rails, tendrá que buscar en otro lugar.
Sin embargo, puede generar la inicial ddl de sus beans Java fácilmente. El siguiente ejemplo ilustra la creación de esquemas con EclipseLink versión 2.0:
<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
<persistence-unit name="JPATestPU" transaction-type="RESOURCE_LOCAL">
<provider>
org.eclipse.persistence.jpa.PersistenceProvider
</provider>
<class>org.randompage.MyEntity</class>
<properties>
<property name="javax.persistence.jdbc.user" value="johndoe"/>
<property name="javax.persistence.jdbc.password" value="secret"/>
<property name="javax.persistence.jdbc.driver" value="org.h2.Driver"/>
<property name="javax.persistence.jdbc.url" value="jdbc:h2:~/.h2/testdb;FILE_LOCK=NO"/>
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
<property name="eclipselink.logging.level" value="INFO"/>
</properties>
</persistence-unit>
</persistence>
El elemento clave aquí es
<property name="eclipselink.ddl-generation" value="drop-and-create-tables"/>
Esto le dice a EclipseLink eliminar tablas existentes y generar nuevos vez de su asignación de APP. Este procedimiento es altamente específico del vendedor, por lo que para otros proveedores de JPA (Hibernate, OpenJPA ...) deberá consultar su documentación específica.
No confiaré en los proveedores de JPA para actualizar el esquema de la base de datos. Compruebe Liquibase para uno de los buenos enfoques.
Leí el libro sobre JPA recientemente. El JPA 2.1 se lanzó en 2013, ¿admite migraciones ahora? – AechoLiu