Hi,
Imagine this use case.
I have 1 changeSet in a change-log.xml file that has an and a with sql inside too. (this is the approach we are talking as some of the people who write the DDL are pure PL/SQL developers and are not so much into xml files. They write the update and rollback scripts, pass them onto me and i add them to change-log.xml.
I run update the database with this changeSet in change-log.xml,
Little later they realised they wanted to change something and they get back to me with the modified SQL and the modified rollback SQL too.
If i change it in change-log.xml and I do run updateDatabase again. (even with runOnChange = true) it will not work.
For such functionality to work, liquibase would have to rollback the first implementation of the changeSet but at that time the content of the rollback tag of that changeSet has also changed.
Nathan, what about this:
We add another column to the database changelog that keeps the neccesart sql to rollback.
If a changeSet changes and runOnChange=“true”, we use the rollback script in databaseChangeLog. Then we run the new sql in the modified change-log.xml.
Wouldn’t this be convenient?
Right now, when I find myself in this scenario, I have to first do a rollBackDatabase, modify change-log,xml and updateDatabase again. If I have different environments (which most people do) I have to do this in all environments in which i had run the changeSet once.
What do you think?
As a side note, you may want to look at http://blog.liquibase.org/2010/05/liquibase-formatted-sql.html which lets you include more standard SQL files they give you without having to convert them to XML if you would rather not.
Having people change changeSets that have already been applied generally concerns me. Even if you provide a rollback, it can be difficult to get the rollback right. I generally suggest only appending changes: if you have created a table and later decide to have it named differently, don’t rollback the creation and create a new one, just do a rename table. It can make for some technically unneeded DDL steps, but I find it to be much easier and safer from a QA and “doing what you expect” standpoint.
Keeping the rollback SQL in the database is an interesting idea. It would allow for safer rollbacks, like you said. It would make your databasechangelog table significantly larger, however, if you have a lot of changesets. It may be worth doing, however, since it would make it easier to rollback and then update again for the runOnChange type changeSets. We would need a different syntax than runOnChange=“true”, however, since that does not expect a rollback to me made, it just expects the changeSet to handle being run multiple times.
Nathan
Nathan,
I can understand your approach of making a changeSet and then just appending things to it. In our case, we have 4 environments. While initially creating the changelog we point to our DEV database. We are using a quiet agile mehtodology. Oftern we implement a set of changes in the database and we discuss about it once the changes have been made. Then we bounce them with the BA or the integration team as they use our database schema for reporting.
If either of them are not happy with our initial approach, then we might decide to drop a column here or there. Believe it or not, this iteration of making changes to the database first and then checking with the BAs and integration time is much more common than in a traditional waterfall environment.
By the time we have all the DDL ready for our release, we generate the neccesary SQL and we give it to the integration team as they are the ones who run DDL statements in PROD.
It feels a bit too ‘trippy’ to pass them SQL scripts with do-es and un-do-es.
I know I am just “wishing” and that I am not aware of the architecture of liquibase and that you probably want to keep things backwards compatible in every sense.
But, just for the sake of the wish, how about this: runOnChange=“true” rollbackOnChange=“true”
Personally, I am the last person concerned about the size of the DabataseChangeLog table.
I really like your work nathan and I would honestly like to contribute but I am just feeling a bit short of breath at the moment.
Regards,
Pablo.
I created issue http://liquibase.jira.com/browse/CORE-735 to track the feature. I’ll look at it as part of 2.1, but if you or anyone else wants to pick it up before that, feel free.
Nathan
