I’m trying to convert an existing database to liquibase and also implement liquibase in an continuous integration environment. I have applied “changeLogSync” to my production database from an ant script via ssh tunneling. That worked fine. I have installed that database into a test integration branch that I can update fine on a different server via ssh tunneling as well.
When I try to run the same exact ant task for updating in our continuous integration environment it tries to run the 1.0 changelog against the database and errors out. I’ve checked and re-checked that databasechangelog exists and that the username and id are the same and that it says “executed” in there as well. I’ve even gone back to my ssh tunnel and run the same ant task and it still works fine.
Does executing the changelog on separate platforms/connections affect the checksum? This is my first time using liquibase so I’m not sure if I’m doing something wrong. Thanks in advance!
Nathan, I was hoping you were going to reply so I can thank you for creating and maintaining such a wonderful project.
They are both on different operating systems. The production database is also on a different server, but I executed that from environment1 with a tunnel as well. This is what I have:
Workstation that I use to tunnel and execute ant
OS X 10.6.4
java version “1.6.0_22”
Java™ SE Runtime Environment (build 1.6.0_22-b04-307-10M3261)
Java HotSpot™ 64-Bit Server VM (build 17.1-b03-307, mixed mode)
Continuous Integration server
7.2-RELEASE-p4 FreeBSD 7.2-RELEASE-p4
java version “1.6.0_07”
Diablo Java™ SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot™ Client VM (build 10.0-b23, mixed mode, sharing)
Thanks for the complement, I’m glad liquibase has been helpful for you.
I have one theory on how they could be different, if you have some changesets with multi-line content with different line feed chars. I just committed a fix to address that. Beyond that, I’ll have to get a linux setup going and do some testing with that.
Are you referring to \r and \n characters? I’ll checkout you change to see if it works. I can also help with some testing as my current release is highly dependent on this database migration. Let me know
Yes, that is what I was wondering about. Perhaps you ended up with someting in your copy between machines that changed the \r and \n’s to match what the platform expects.
RC7 is out, if you could test with that and let me now how it goes, that would be great.
Still the same result. I tried it from an automated build, and from the command-line itself on the server. When I tunnel in again from my workstation, it committed my changelog 1.1 changes just fine. Also, I’m using source control to check out the files on both servers, would there still be issues with different line feed chars? Thanks and I look forward to your reply.
I didn’t realize that the checksum was changed again from RC6 to RC7, so I’ll have to re-try this again. I need to first re-sync the database to a 1.0 changelog, then try an update. Thanks
Originally posted by: Nathan
Yeah, it should have been in the release announcement. I was hoping it would be more transparent, but there are a few cases where it is not.
I’m working on a project where we got burned by the checksum change algorithm between 1.9.5 and 2.0-rc6. Could you detail the change from 2.0-rc6 to 2.0-rc7, please?
At the moment, the database in question is all up to date with respect to 2.0-rc6 changelogs. I’ve been carefully keeping up with your (many :-)) release candidates, but am unsure what has changed in this area between rc6 and 7.
If it helps, my changelogs are simple createTables, insert data refactorings, etc. Not much custom SQL if any.
There was a change in which I added an extra newline standardization into the string we md5sum. The idea being that sometimes when a changelog file is transferred between platforms, ftp and other protocols will change linefeed characters to help the transition. In order to keep checksums the same no matter the underlying platform, we now replace them all with \n.
The goal is to never have to change the checksum algorithm, which is part of the reason for the many RCs: once 2.0 final is out, I do not want to have to change them again, like how we went for four years or so in the 1.x series.
That being said, with 2.0 I did introduce a versioning into the checksum, so liquibase can more gracefully handle checksum changes. If we have to change the algorithm (such as from 1.9.5 to 2.0 and RC6 to RC7) liquibase will not fail, but will update them to the newer version. The only problem is knowing if there was a valid change between versions, that is un-detectable.
So RC6 to RC7 should silently update your checksums and the only thing you should notice is if you expected a runOnChange to run, it will not, and if you make a change you will not get a checkum error. If you do have only non- changeSets, you should be able to run an sql statement that replaces “2:” with “3:” in databasechangelog.md5sum. Multi-line insert statements may be different as well, however.
we have the same problem at all. We use eclipse and ant-plugin for executing liquibase. liquibase version is 2.0.5. We have statements which did not change (no difference when using tortoise diff between the versions, except the new added statements.), but we get liquibase-error, that change set checksum validation failed. We use custom sql.
