I would be very interesting in a feature where you could see what was actual order of applied scripts. if you apply one script per day then you can easily use dateexecuted for that. but the issue is that I am running lots of scripts at one time - then dateexecuted is not the best thing to trace order of scripts.
The issue arises when we manage a db with scripts which are maintained on different branches.
Does liquibase has a feature for that now?
if not would it be possible to have it? I guess the simplest way would be to have additional column in databasechangelog which would have an uniqe sequential number: this number would be populate by an insert statement that liquibase generate: this insert statement would populate this column by using select like this: select max(seq) + 1 from databasechangelog
So, once Liquibase is run, the order of execution of the changeSets is completely lost. This makes some features such as rollbackCount completely useless. The use of a sequential surrogate primary key in the databasechangelog table would fix the issue (with serious compatibility implications).
Originally posted by: mica89
The issue arises when we manage a db with scripts which are maintained on different branches.
I agree that it is something that should be looked at for 2.0. Implementing it will require a change to the databasechangelog table, and I am not wanting to deal with that except for in major revisions.
We cannot use sequences because they do not exist on all databases. We should be able to select the max value from a new “applied_order” column in the databasechangelog table and increment it when doing an update, but I am afraid that we will get incorrect values when using updateSQL. It is a problem that needs to be fixed, however.
I see issue CORE-175 was updated with this thread. I increased the priority and assigned it to 2.0
Originally posted by: Nathan
I agree that it is something that should be looked at for 2.0. Implementing it will require a change to the databasechangelog table, and I am not wanting to deal with that except for in major revisions.
That’s great news!
Originally posted by: Nathan
I see issue CORE-175 was updated with this thread. I increased the priority and assigned it to 2.0
Originally posted by: mica89
The issue arises when we manage a db with scripts which are maintained on different branches.
I didn’t understand this point.
Initially we were using naming convention to have ordering out of the box: script names started with a number. This works perfectly fine assuming that we always add a new script with a larger number - and we have addded each script to the trunk. Howver, then we have started to add a scripts also on our version control system on the branch. Then we had to introduce another naming convention in case of a branch (subnumbering). However, we have many time cases where we need to merge back and forth - then the numbers in the file name started to be useless.
So what we know is: we can use numbers in the names and they will defeinetly tell us in what order script has been created - however, such number will not tell us in what order the script has been actually applied. So then I think the only way is to trace this order in the databasechangelog table itself.
Originally posted by: mica89
So what we know is: we can use numbers in the names and they will defeinetly tell us in what order script has been created - however, such number will not tell us in what order the script has been actually applied. So then I think the only way is to trace this order in the databasechangelog table itself.
Your analysis is correct. You seem to use a one-changeSet-per-changelog approach which is the same we are using here. To avoid some of the branch merging problems, we adopted the convention of always committing a bug-fix-changelog to both the branch and the HEAD (trunk). We use the same name for the two changelogs, so that, when we are migrating from the branch-version to the HEAD-version, the changelog is not executed again. To guarantee the uniqueness of the changelog we use the following convention for the filenames:
-YYYYMMDD-HHmm.xml
Where YYYYMMDD-HHmm is the date with minute precision. As you said, the date in the filename does not necessarily indicate the execution order.
Originally posted by: diegomrosa
You seem to use a one-changeSet-per-changelog approach which is the same we are using here.
Yes. We have many developers in the team and that is the only way to distribute scripts smoothly: checkin small scripts immediately.
Originally posted by: diegomrosa
To avoid some of the branch merging problems, we adopted the convention of always committing a bug-fix-changelog to both the branch and the HEAD (trunk). We use the same name for the two changelogs, so that, when we are migrating from the branch-version to the HEAD-version, the changelog is not executed again.
We do the same:
- for bugfixes we merge immediately
- we do not change file names to make sure that branch and main db can be synchronized easily.
But sometimes merge cannot happen immediately because the fix (or some feature) might take sometime - but we do checkin script as early as possible (but not too early :).
Originally posted by: diegomrosa
To guarantee the uniqueness of the changelog we use the following convention for the filenames:
-YYYYMMDD-HHmm.xml
Where YYYYMMDD-HHmm is the date with minute precision. As you said, the date in the filename does not necessarily indicate the execution order.
for main we use convention:
XXXXX.[schema/data]..xml
where
-XXXXX is a consecutive number (with leading zeros)
- schema/data - whether the change is related to schema or to data only.
and for the branch we use
XXXXX.XXX.[schema/data]..xml
same as for main but with subnumbering: primary number is not changed.
As we recently encounter more and more development on the branch we have noticed that the convention stopped reflecting the execution order of the scripts. So the feature to know the exact order of the execution would be very welcome by us.
