A new feature in ORDS 22.1.1 is a report for Liquibase changeLogs applied to your schema.
I apologize this isn’t listed on the Readme/Release notes for 22.1.1, I’m fixing that now.
Liquibase keeps track of what’s going on in a schema with a DATABASECHANGELOG table. So if SQL Developer Web sees that table…
Opening up the LIQUIBASE card, I’ll be able to see a few different things.
Maybe you have a deployment running (via UPDATE)?
Liquibase applies a locking mechanism to prevent multiple changeLogs from being applied concurrently, hence the ‘Locked’ icon (Liquibase Docs).
My changeLog has 74 changeSets to be applied…I think I got this screenshot inbetween it finishing and the page refreshing to reflect the new status, but you get the idea.
Reviewing changeLogs
What’s been deployed? Who deployed it? How was it deployed? What did my object look like BEFORE the UPDATE was applied?
Seeing these now, I’m thinking I should probably starting naming these puppies or using some predictable patterns?
Anyways, let’s click into the big one.
We extend what Liquibase tracks in your schema. We also include what the previous state was (which allows us to do automated Rollbacks later), and we also show you what was actually applied via the database.
Since the changeSet actually caused the table to be created, there was no previous state of the EMPLOYEES table to record.
But, what if we say…add a column and constraint to my table?
ALTER TABLE EMPLOYEES
ADD (POTPOURRI BLOB );
ALTER TABLE EMPLOYEES
ADD CONSTRAINT EMPLOYEES_CHK1 CHECK
(potpourri IS JSON)
ENABLE;
I’ll apply this in my DEV environment, generate a changelog using SQLcl via…
lb genobject -type table -name employees
This will generate an XML-based change I can then apply.
So I apply it…
lb update -changelog employees_table.xml
Tip: if you’re in interactive mode (vs pushing changes via automation pipelines), test your update with ‘updatesql’ first – you’ll see if it’s going to do what you THINK it is.
I’ve applied the change to my schema, let’s see what it did.