Having troubles understanding how Liquibase works

I’m building a web app which will support multiple installation of different servers for multiple customers, both the development code and development DB (SQLite3) are on a remote server (debian 10). So far no issues, I’ll install Liquibase on the dev server and run the generateChangeLog command to generate my changelog for the current status of the DB, now the issue I’m having is, if I have to create a new table or a new column on my DB, do I have to create a new changelog with all the changeset inside? Or I can simply manually edit the DB and run generateChangeLog again?

After that, to migrate the changes on the production servers I’ll install Liquibase on each server, download the updated code with the changelog files from my git and run the update command? Is that all? Will liquibase manage it’s own internal versioning? What if I make more changelog files, will Liquibase know which one to run first?

I know they’re all dumb questions but for some reason I can’t clearly understand how to make all of this work.

Thank you all

Hi Daniel. They’re not dumb questions at all.

You have a few options when adding new changes to a changeset:

  1. (Recommended) Add the changeset manually by writing the XML/JSON/YAML/SQL yourself.
  2. Snapshot & Compare scenario
    a. Snapshot your database before you make changes.
    b. Make changes to your database
    c. Perform a diffChangeLog between the live database and the snapshot in created in step ‘a’ to generate changesets for ONLY what has changed. This can be added to your existing changelog file(s)

Liquibase does manage its own internal versioning. Ordering depends on how your changelogs are structured, but generally changesets will be deployed in the order they appear in the changelog.

If you’re getting started with Liquibase I strongly recommend you check out Liquibase University (https://learn.liquibase.com). It covers all the questions you have and more. It is a great time saver and starting point.

2 Likes

Hi Pete, thank you for your message! I’ve been playing with the demo Databases yesterday and it’s all more clear.

  1. (Recommended) Add the changeset manually by writing the XML/JSON/YAML/SQL yourself.

Perfect i’ll do that then

If you’re getting started with Liquibase I strongly recommend you check out Liquibase University (https://learn.liquibase.com ). It covers all the questions you have and more. It is a great time saver and starting point.

Looks great, if i have some time today i’ll do this course :smiley:

Thank you for everything

1 Like

Building on what Pete said, it might be helpful to use an include tag and a sub-directory to split up your changelogs. For example, here is our main changelog.xml file

Screen Shot 2020-09-04 at 11.59.46 AM

and then we simply build out that sub-directory with the relevant changesets:

DEVLAPTOP:schema ekolp$ ls -lash
total 96
0 drwxr-xr-x 14 ekolp staff 448B Aug 14 11:28 .
0 drwxr-xr-x 17 ekolp staff 544B Aug 26 12:32 …
8 -rw-r–r-- 1 ekolp staff 1.2K Jul 28 10:54 220.xml
8 -rw-r–r-- 1 ekolp staff 1.1K Apr 23 11:39 221.xml
8 -rw-r–r-- 1 ekolp staff 3.4K Aug 14 11:28 222.xml
8 -rw-r–r-- 1 ekolp staff 2.0K Aug 14 11:28 223.xml
8 -rw-r–r-- 1 ekolp staff 1.5K Aug 14 11:28 225.xml
8 -rw-r–r-- 1 ekolp staff 2.3K Aug 14 11:28 226.xml
8 -rw-r–r-- 1 ekolp staff 2.0K Aug 14 11:28 227.xml

It runs them in sequence so you can “build up” your database by way of many changesets.

2 Likes

Hi @erinlkolp,

yeah, I’m now exactly working on that, I’m having a few issues with it since for some reason I’m getting an XML Parsing error, it might be because I’m using .sql changelogs and not .xml but it doesn’t make sense :confused: I’ll probably have to make another post asking for help there, so to keep the forum cleaner and easier for other people in the future :slight_smile: