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…

This card will show you what’s been applied to your schema…and much more.

Opening up the LIQUIBASE card, I’ll be able to see a few different things.

Maybe you have a deployment running (via UPDATE)?

I’m running an UPDATE via SQLcl right now, and I can see what’s going on…

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?

I’ve got two changeLogs that have been applied, one big one, one tiny one.

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.

SQLcl names the XML based changelogs via the name and type of object.

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.

How did we create this table?

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?


(potpourri IS JSON)

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.

What had had happened to my table, and what it looked like prior to the update.

I'm a Distinguished Product Manager at Oracle. My mission is to help you and your company be more efficient with our database tools.

Write A Comment