04-23.eri-test Liquibase：请勿将ISO日期用作yml的变更集ID

\n

After upgrading a service from java 8 to java 11, our liquibase got crazy and tried to apply every change to the database from the beginning. But they were already applied and no changes were made to the database.
\nWe discovered that using ISO dates as identifiers of the changeset was a bad idea. The hard way.

\n

\n \n \n \xc2\xa0Liquibase Changesets\n

\n\n

Changesets in liquibase are, as their name implies, a set of changes that must be applied at once in a database (or not at all).

\n\n

In order that liquibase is able to distinguish when a changeset is already applied or not, it requires you to set a unique identifier.

\n\n

By convention, we started to use the ISO date when the change was written (format yyyy-mm-dd).

\n\n

For example:
\n

\n\n

databaseChangeLog:\n- changeSet:\n    id: 2019-06-06\n    author: sergiomoratilla\n    comments: Adding new value to know which client was used to book.\n    changes:\n    - modifyDataType:\n        tableName: reservation\n        columnName: client\n        newDataType: ENUM(\'WEB_DESKTOP\', \'WEB_MOBILE\', \'APP_ANDROID\', \'APP_IOS\', \'UNKNOWN\') NOT NULL\n

\n\n\n\n

Liquibase stores the applied changeset in a table called DATABASECHANGELOG within your schema. So that, we were expecting a row
\n

\n\n

"2019-06-06"    sergiomoratilla /liquibase/changelogs/this-example.yml ...\n

\n\n\n\n

\n \n \n It\'s a trap\n

\n\n

Liquibase\'s YML parser decides to get the changeset id as a Date, and then use toString() to generate the id. That smells because you don\'t have control on that format... and this is exactly what happened.

\n\n

Instead of storing "2019-06-06" we got "Wed Jun 06 00:00:00 GMT 2019".

\n\n

After upgrading to Java 11, the behaviour of toString() changed and now returns "Wed Jun 06 02:00:00 CEST 2019". It is exactly the same date so that this format is correct but it is a bit weak to trust your ids to default formatting.

\n\n

\n \n \n \xc2\xa0Solutions\n

\n\n

Don\'t use ISO date as ids (if you are using yml format to configure that). Probably, most of you didn\'t already do that.

\n\n

When we started to have several changes on the same date, we decided to change that format to yyyymmdd-n, where n is an incremental integer.

\n\n

What if you are already using them? I suggest you to replace the ids in your changelogs files by the ids you already have in your database. And change your convention for new files!

\n\n\n