Liquibase YML ChangeSet IDs (double vs string)

General Discussion
1

Hi,

I have a project that was using liquibase 3 that was upgraded to liquibase 4.

One issue we encountered is related to how changeset IDs were assigned in the yml files

databaseChangeLog:
  - changeSet:
      id: 000001
      author: ddewaele

Notice the absence of quotes in the id field here.

In the database changelog table this resulted in the following weird behavior when it came to liquibase changeset ID generation in the ID column of the table (that is used to match changesets)

yml id: 000001 -> DB column ID : 1
yml id: 000002 -> DB column ID : 2
yml id: 000003 -> DB column ID : 3
yml id: 000004 -> DB column ID : 4
yml id: 000005 -> DB column ID : 5
yml id: 000006 -> DB column ID : 6
yml id: 000007 -> DB column ID : 7
yml id: 000008 -> DB column ID : 8.0 ( here during the changeset yml parsing all of a sudden liquibase parsed this as a double and put it like that in the database)

When we switched to liquibase 4, changeset ID generation apparently changed and turned into this :

yml id: 000001 -> DB column ID : 1
yml id: 000002 -> DB column ID : 2
yml id: 000003 -> DB column ID : 3
yml id: 000004 -> DB column ID : 4
yml id: 000005 -> DB column ID : 5
yml id: 000006 -> DB column ID : 6
yml id: 000007 -> DB column ID : 7
yml id: 000008 -> DB column ID : 000008  (notice how here it was not parsed as a double but stored as a string now)

As a result, because the ID generation is different, we were not able to deploy our new version of the app because liquibase tried to re-apply changeset id: 000008 as with liquibase 4 all of a sudden a changeset id “000008” was generated that did not exist before (it existed as changeset id “8.0”

I can see how not putting quotes in a yml file to assign a changeset ID can be ambiguous (should it be considered a string or a number) and that quoting these IDs would solve it, but was wondering if this was a bug and how you would recommend us solving it ?

I would like to put quotes in these changeset ids (just to avoid these types of ambiguity) but need to find a way to make sure the database changelog is updated accordingly without all of these database changesets to be executed again (because nothing changed on the database side)

databaseChangeLog:
  - changeSet:
      id: "000001"
      author: ddewaele

What would be a good way forward here ?

2

The ID column is varchar (Oracle), so I assume that this change to “properly” interpret the changelog ID value in 4.x was on purpose.

But I would ask: Why are you using zero-padded strings as ID? why not just 1, 2, 3, etc? I always recommend people use a meaningful text-string, like “Add-Column-XYZ” or something.

3

It was an existing changelog. I think somebody started with 00001 and then it just continued.

But still the logic behind the numbering is a bit weird and not consistent.

Don’t know why for some entries it converts it to “7” and for others it converts it to “000008”.

We also saw other entries where the IDs in the database did not match with what was in the yml. ( in some cases we saw id:000009 being converted to “8”.

I tried debugging it and noticed it was already ill-converted in the low-level yml pasing but didn’t find the root cause.