I am working on a web application that allows me to give my DBA a way to review and apply liquibase changes. The web framework that i’m using, wicket, makes extensive use of java serialization.
I see in the liquibase code that there is an interface, LiquibaseSerializable, that covers a super set of the liquibase classes that I need to serialize.
What would be the pitfalls of making ChangeSet, DatabaseChangeLog, and RanChangeSet implement java.io.Serializable?
That is a good question. In theory it should be fine, I’ve just not put in the various transient etc. flags for things that are instance-specific and shouldn’t be auto-serialized. It would probably be worth looking into.
How is wicket using serialization?
Nathan
I have been using Wicket for so long that I take it for granted that Wicket is serialization centric and haven’t thought about the the theory of it in a long time.
This somewhat dated page nicely describes the philosophical difference between wicket and more Servlet API centric frameworks: https://wicket.wordpress.com/tag/difference-between-wicket-and-struts/
Because wicket is maintaining a conversational flow with each client using a programming model that sort of resembles swing, It needs a mechanism to let many concurrent conversations carry on this model. To do it serializes and reconstitutes components (pages, page fragments, and models that represent the data that is being operated on).
So far, I’ve chickened out of making my own liquibase fork and making those classes serializable. Instead I made my own classes and copied the data from the liquibase classes that have that information.
In conclusion, my life (and maybe other developer’s lives as well) would be slightly easier if liquibase classes that model the change oriented information implemented java.io.Serializable
