1
votes

I came across the below document for liquibase but confused about the wording on how it identifies the unique change. https://docs.liquibase.com/concepts/basic/changeset.html

It says:
'If it has been run, the changeset will be skipped unless there is a runAlways tag set to true in that changeset. After all the changes in the changesets are run, Liquibase will insert a new row with the id/author/filepath along with an MD5Sum of the changeset in the DATABASECHANGELOG.'.

My question here is:

  • If change is uniquely identified when ALL of these 3 attributes are different from what is stored in DATABASECHANGELOG table? Or
  • Change is uniquely identified when ANY of these 3 attributes is different from what is stored in the changelog table.
2

2 Answers

0
votes

From the DATABASECHANGELOG table docs:

The table tracks each changeset as a row, identified by a combination of the “id”, “author”, and “filename” columns. There is no primary key on the table. This is to avoid any database-specific restrictions on key lengths. The composite of “id”, “author”, and “filename” is unique across all rows of the table.

Meaning if any of the attributes are different, it is considered as a new, unique entry and Liquibase will not compare MD5Sum with any already existing rows in that table. Even though the ID values are the same for example, which may not come as obvious when you are starting to work with Liquibase.

0
votes

The primary column of the table DATABASECHANGELOG consists of the three columns you mentioned (at least in liquibase version 2.0.5, which is quite ancient):

ALTER TABLE databasechangelog 
  CONSTRAINT pk_databasechangelog 
  PRIMARY KEY (id, author, filename);

As @veljkost pointed out, the current version 4.3.2 hasn't got a primary key as some database vendors limit the length of an index.