Hi,
I have integrated Liquibase for installing our application from a Hibernate Mapping including ForeignKey, Indexes, Id-Generators and UniqueKeys and to upgrade existing customer installations by using xml-changelog files.
So whenever a new feature requires a db-change we add both the hibernate annotations and a according changeset.
My problem is that if I install the application for the first time, I have no way to find out which ChangeSets are already included by the Installer (Hibernate Mapping) and which ones must be included by the Updater because the Installer doesn’t know about them. At this time the DATABASECHANGELOG Table is empty, so by default all changesets are shown.
I thought of a solution based on a release date. The Updater only includes changesets released after the installation date.
This might be realized by:
-
Introduce a new optional attribute (releaseDate=“2010-11-15 12:00:00”) to ChangeSets. (@Nathan: I will create a improvement-issue in Jira and attach a patch if this way is ok with you.)
-
Write a Liquibase extention <ext:released on=“2010-11-15 12:00:00” />
What do you think about that? Are there any alternatives for solving my problem?
Thanks,
Michael
(sorry for the slightly slow reply)
I’m not sure I quite understand your update process. Is there a break between existing pre-liquibase installs vs new installs? For that, I generally use a starting changeset that defines the “legacy” state of the database for existing installs, then use a precondition such as a to see if they need to be ran. If you set onFail=“MARK_RAN”, if the precondition fails, the old changes are marked as ran. If the precondition passes, all the changesets are ran. The generateChangeLog command works well for this sort of migration path.
If you are looking to solve a different problem, let me know.
That being said, the goal of the extension system is to be able to create and share functionality that isn’t in the core liquibase because it doesn’t or shouldn’t apply to most people, but would be very helpful for some. I can see times where the releaseDate extension would be very helpful, and I think it would be great to create. I don’t think I would want it as a standard feature at this point, but it would make a great extension.
Nathan
Hi,
My installer always creates the DDL for new installs on-the-fly from the hibernate mappings right within the application (not at build time). This might not be the typical way for using liquibase in the update process.
Because of my specific problem, I also think creating a “releaseDate” extension is much better than integration such feature to the core.
Thanks,
Michael
It is often best to not depend on mappings to determine DDL since you cannot tell the difference between a rename column and a drop one column add another, for example. But it may not make sense for you, depending on your use.
If you have any questions on the extension, be sure to let me know.
Nathan
