A pre-condition in our project is that we can not use liquibase upgrades in our verification and production environment. So, we cannot run liquibase diffChangeLog against those databases in order to extract changeLog’s that would tell us what changes need to be done in the database.
So, what I was thinking of using is the tag column in the databasechangelog table. However, I am not sure how I can control the value of that column. I tried “liquibase tag” but it updated only the latest record in that table (there were timestamp difference within the same second, i.e. millisecond difference).
What I would like liquibase to do would be to tag all changes for which records are created in the databasechangelog table.
Or am I misunderstanding the maven tag target ?
Or do you have any other suggestions for best practices in this scenario.
The tag command will just enter a value in the databasechangelog for the last change applied. If there are multiple changes with the same max(time) they will all be tagged which can lead to confusion (fixed in liquibase 2.0 with an ‘orderexecuted’ colun). The reason we don’t tag all of the changes is because we have just a single column and we don’t want to overwrite other, older tags.
The normal/best liquibase use, however, is to not use the diffChangeLog command but to build up the changelog manually during development. That way you don’t have to worry about what has been applied or not in other databases, you just need to append changes to get it to work in your dev enviornments. When you get to a release point, you can either run liquibase directly against another database, or use the generateSql to output a script that can be run against the other databases. You can use liquibase in other ways (including the diffChangeLog) but they do not work as well. See this post for a discussion on some of the limitations of database diffs vs. during-development updates in general.
The word not should be there. at least not as part of a normal process.
The most accurate way to build up your changelog is add the changes you need one by one as you need them for new functionality. The diffChangeLog command works for cases when you cannot build up the changes one by one, or as a sanity check, or to help you get going with liquibase.
The diffChangeLog command is not robust enough to rely on as your primary means of tracking changes, and even if it was it would suffer from the diff problems descrbed in the link.
In our verification and production environment we have DBA’s that execute the changes to the database. We don’t have databasechangelog in those environments!
So, it is not possible to run “liquibase update” for these environments. So, how do we get help from liquibase in this case?
Originally posted by: Nathan
The tag command will just enter a value in the databasechangelog for the last change applied. If there are multiple changes with the same max(time) they will all be tagged which can lead to confusion (fixed in liquibase 2.0 with an 'orderexecuted' colun). The reason we don't tag all of the changes is because we have just a single column and we don't want to overwrite other, older tags.
The normal/best liquibase use, however, is to not use the diffChangeLog command but to build up the changelog manually during development. That way you don’t have to worry about what has been applied or not in other databases, you just need to append changes to get it to work in your dev enviornments. When you get to a release point, you can either run liquibase directly against another database, or use the generateSql to output a script that can be run against the other databases. You can use liquibase in other ways (including the diffChangeLog) but they do not work as well. See this post for a discussion on some of the limitations of database diffs vs. during-development updates in general.
Nathan
What I am requesting a functionality of the “update” command, meaning that all changes applied to a database within the same “update” execution could be taged with some tag property provided. In that way records in the databasechangelog table could belong to different tags, i.e. releases. /Lasse
I’m trying to understand what you are asking for. You are looking for a way to tag all the changes that were applied in a given update so they can be extracted by tag and used to update production? Or is that not what you are looking for?
The way I have generally used liqubase with DBAs is to use the updateSql command. The concept there is that you use liquibase like you normally do during development (devs add changeSets one at a time as they need individual changes), but when you come to release time, you don’t run the built up changelog against the database directly, instead you run updateSql against the production database (or a copy of production, or even just a database with a copy of production’s databasechangelog file). UpdateSQL does not actually execute anything, instead it outputs an SQL script including all the changes in the changelog and the inserts into databasechangelog to move the database to the current state. You give the output SQL to your DBAs who look it over, tweak it, approve it, then run the script against the production databases.
As part of the “hand over to the DBAs” step, you can also run dbdoc to generate documentation on what changed as well as run “futureRollbackSql” which will output the SQL needed to undo the new database changes and bring the database back to the point it was at before the upgrade.
To bring it back to your question, you may be able to find a way to implement similar functionality to the above using the tag command, but using a workflow similar to the above is going to be much more reliable and fit best into what liquibase is designed to do.
Ok, I understand what you mean. We will try that. What I wasn’t aware of was that the updateSQL gave me inserts to get DATABASECHANGELOG in the current state.
What was a problem for us was to “convince” DBA’s to run changes of a database with Liquibase. It is their domain so to say and can be a bit difficult.
I understand. We do try to keep as low-profile as possible by adding only two tables and supporting the generateSQL mode. If they have additional suggestions on how we could be more DBA friendly, be sure to let us know.