As part of an application upgrade that has taken the app from Hibernate 3 to Hibernate 5 and Liquibase 2 to Liquibase 4.8 we’re suddenly facing thousands of newly detected changesets.
90% of these changesets are ‘dropDefaultValue’ which although shouldn’t be there, shouldn’t cause any issues if they do run.
But there other 10% look like they would potentially cause problems.
Due to the size of the detected changes, it takes a long time to gather this changelog, we’re using groovy and the resulting groovy file is too big to run with updateSql without first splitting it into separate files manually due to the maximum size of a groovy method.
What I really would like is to somehow inform liquibase that this new changeset should not be processed but ensure it doesn’t regenerate the same changesets the next time we look for changes.
What I’ve tried was to generate the SQL from the changesets, and went through commenting each statement leaving it to only add the changelog table entries. Unfortunately this isn’t enough as the next time I checked for changes, it produced exactly the same changesets.
The upgraded application is working perfectly with the database in it’s current state so I really don’t want it to detect any changes, but clearly it is, and I’m at a loss how I can continue to use Liquibase for future changes without it wanting to make all these modifications.
Any advise on this matter would be much appreciated. Thanks.