Combina la creazione automatica dello schema di Hibernate e il controllo delle versioni del database

Question

Ho un'applicazione in cui Hibernate crea tutti i miei schemi di tabelle ogni volta che l'applicazione viene eseguita su una macchina per la prima volta. Funziona bene

Ora ero però chiedendo se Hibernate ha una sorta di meccanismo per mantenere il database sotto controllo di versione, vale a dire si Hibernate sa come migrare uno schema a un altro quando si esegue una versione diversa della mia applicazione e Hibernate trova un database diverso schema da una versione precedente presente? In qualche modo penso che ciò dovrebbe essere possibile, considerando che Hibernate può leggere lo schema esistente e potrebbe confrontare lo schema con la descrizione della mappatura. Tuttavia, non saprei come dire a Hibernate di migrare i vecchi dati come quando si creano script di modifica con ad es. Liquibase/Flyway.

Probabilmente non ho cercato su google le cose giuste poiché Hibernate e il controllo delle versioni ti mostreranno molti successi sul controllo e sul controllo delle versioni, ma sto pensando più in termini di versioni di Liquibase/Flyway. Non ho mai preso in considerazione entrambi, ma poiché Hibernate non crea script di aggiornamento ma manipola direttamente il database, non saprei come far funzionare entrambi.

Questa è la prima volta che Hibernate crea il mio schema invece di scrivere i miei script. Lo faccio per fare uso di Hibernate Envers ciò che rende la creazione di script manuale estremamente noiosa. Forse mi manca qualcosa di ovvio. Grazie per qualsiasi input su questo argomento!

Aggiornamento: Ho avuto modo di parlare con lo sviluppatore di Flyway oggi e mi ha detto che non avrebbe saputo di una buona soluzione. Forse non c'è niente?

Answer 1

Abbiamo avuto lo stesso problema con il nostro progetto Java/Hibernate e non volevamo uno sforzo di duplicazione del codice. La funzione di "aggiornamento" di Hibernate non è affatto affidabile, LiquidBase è migliore, ma non del tutto infallibile al 100%. Alla fine abbiamo sviluppato un semplice script per gestire il processo seguente:

1. Lo schema del database "corrente" viene sempre generata da Hibernate, rispetto a un database DEV direttamente.
2. Uno schema di database "precedente" è generato da una serie di set di modifiche LiquiBase.
3. Ogni volta che è necessaria una migrazione , una funzione LiquiBase "diff" viene richiamato tra i "precedenti" e le banche dati "correnti" (due basi di dati attuali, sì, in modo più affidabile in questo modo), generando un nuovo set di cambiamento LiquiBase .
4. Questo set di modifiche deve essere rivisto manualmente. Tutti i set di modifiche sono mantenuti nel controllo del codice sorgente.
5. Il database PRODUCTION ha lo schema generato applicando tutti i set di modifiche LiquiBase.

un comando chiave nella nostra script legge come il seguente:

${LIQB_COMMAND} ${PREV_DB_OPTIONS} --changeLogFile=${LIQB_CHGLOG_FILE_NEW} \ 
    diffChangeLog \ 
       --referenceUsername=${DEV_DB_USER} \ 
       --referencePassword=${DEV_DB_PWD} \ 
       --referenceDriver=com.mysql.jdbc.Driver \ 
       --referenceUrl=${DEV_DB_URL} 

In questo modo, il nostro processo di migrazione è abbastanza affidabile e non scrivere il codice dello schema due volte. Esiste una revisione manuale del set di modifiche generato in XML, ma la maggior parte delle volte non c'è alcun problema, ed è sicuramente molto più facile della scrittura manuale delle operazioni di modifica dello schema.