Custom change: can I designate a field as not affecting the checksum?

We are using Liquibase 2.0.1.  (Subsequent versions add PRIMARY KEY DDL fragments to almost every DDL line in the Informix support.)


Here are my class signatures, condensed etc. for brevity:


http://about.me/lairdnelson

Is there a way to designate a particular attribute of a custom change as not affecting the changeset’s checksum?


Background: I’ve written a column copying change/refactoring element that accomplishes copying and data conversion through a JDBC driver, rather than in SQL (Informix, curse its awful soul, can’t convert a VARCHAR to a TEXT column in SQL).  To make this reasonably performant I’ve added a fetchSize attribute.  I now can’t add this attribute to our existing usages of this custom refactoring element because it alters the checksum of the changeset of which they are a part.


I know that Liquibase features some annotations to help in this general area, but I couldn’t find anything obvious.


Best,

Laird


http://about.me/lairdnelson

What version of liquibase are you using? 2.x? And by “custom change” do you mean a customChange implementation or a class that actually extends the Change interface as a liquibase extension?

Nathan

That’s what I was trying to remember; thank you!


http://about.me/lairdnelson

Thanks for finding that nessumo. I did create https://liquibase.jira.com/browse/CORE-1330 to separate out whether a field is serializable from whether it is used in checksums.


Nathan

I guess you can use AnonymousChange for exemplary use.

In 3.0.7 the annotation changed to DatabaseChangeProperty. There is probably too much connection between “all properties” and “serializable properties” and “properties to checksum”. I should clean that up more in 3.1.  


You can set the @DatabaseChangeProperty(isChangeProperty  = false) attribute and that should allow your change to still work but will not try to checksum it.


I created https://liquibase.jira.com/browse/CORE-1634 to track the API changes


Nathan

Hmm… I have problem now, during upgrade to 3.0.7. Above annotation is no longer available, but your issue is not yet solved. Any idea? :wink: