I agree that it is nicer to maintain a description, but what you are basically doing is a database diff between the current database and a description snapshot. I think that is very dangerous and something liquibase was actively designed to avoid (See pre-liquibase 1.0 blog post http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html)
I think the “database version control should be like source version control” is an easy and natural assumption devs make, but database changes requiring a semantic meaning of what changed, not just a syntactic meaning is extremely significant.
That is why I think it is best to have a change set built up of descriptive steps. It not only preserves the intent of the change, but it also ensures that all current and future database updates follow the same flow which allows you rely on past QA testing of the update process.
In the initial design of Liquibase, was snapshot-to-snapshot migration considered?
What I mean is: in Liquibase today, you typically add a relatively tiny changeset that performs a relatively tiny operation against an old state of things, and that results in a new state of things. You do not change the description of the way things should be, and then have Liquibase Make That So.
I was curious if there were reasons for not following this snapshot-to-snapshot approach to migrations.
My team has found that in real-world applications they feel it is cumbersome to have to correct a misspelling, for example, by actually adding a change set that renames a column. They would rather somehow (if it were possible, obviously) just change the “description” of a given table so that the column name was no longer misspelled, and have Liquibase somehow infer the ALTER TABLE statement behind the scenes.
I have mixed reactions here. On the one hand, this seems totally reasonable. You “version” state A, then you “version” state B, and Liquibase takes care of implementing the transition from state A to state B automatically.
On the other hand in many cases I could see the transition implementation being quite difficult. I would be curious to hear what you considered here, what you rejected, and what you simply haven’t had time to do.
