First of all, thank you for the great work on liquibase!
I am starting to integrate liquibase in order to industrialize database schema migrations on Jspresso based applications (Maven/Spring/Hibernate). The objective is to be able to generate version to version migration scripts as much as possible and complete them with manual changes when needed. So far, I’ve come up with a working solution using a combination of the liquibase Maven plugin, liquibase-hibernate plugin and HSQL.
The process is the following :
- store a file-based HSQL schema in the project versioned source tree (aka current). This schema should evolve by following the development progression.
- use the generateChangeLog goal to generate the install changelog for a version based on the Hibernate model (fresh for every build). The install changelog is stored in the source tree per version.
- apply it (update goal) to a fresh in-memory HSQL instance (aka reference).
- use the diff goal to generate/update a diff changelog between the current and reference. This diff changelog is also stored in the source tree per version.
- update the current using the diff changelog in order to align it with the reference and make it ready for next build diff change generation.
So far so good
I still have some questions pending :
I’ve hit a problem on the latest release 3.5.3 regarding re-creation of untouched foreign keys on Hibernate entities inheritance mapping (I think that it is linked to CORE-2928). 3.6.0-SNAPSHOT works fine. Is there a public maven repository for liquibase snapshot artifacts ? Any planned date for a 3.6.0 release ?
When generating the diff changelog, I couldn’t find a way to force the author of the changesets like I can do it for the generateChangeLog goal using the changeSetAuthor configuration parameter. Am I missing something ?
A more general question regarding the Hibernate Dialect used for generating the changelogs from the Hibernate model (install and upgrade). What is the impact of the used dialect on the changelogs ? As I understand it, there shouldn’t be any since there is no DB-specifics in the produced files, but correct me if I’m wrong.
I tried to force the dialect to org.hibernate.dialect.HSQLDialect during the build by using the dialect URL parameter (e.g. hibernate:spring:org/jspresso/hrsample/core-config.xml?bean=hibernateSessionFactory&dialect=org.hibernate.dialect.HSQLDialect) but AFAICT, it does not override the onde declared in the Spring configuration (wich might be the one of the targeted production database). It’s not a big thing if (3.) is ok, but can be problematic if not. Again, am I missing something ?
Thank you for any advice and sorry for such a long post…