Recommended to record all liquibase changesets in one database when managing multiple databases?

Question

I am working with an existing application that has two different databases that it uses, and a bunch of pre-existing SQL statements. The databases are:

1. App
2. Logging

They do not share a schema but they both are used while the app is running.

QUESTION: Is it OK, preferred, or frowned upon to record all change sets under one of the databases?

Here is some background. When I first started testing liquibase against these, I was trying to select the database at runtime and was running into errors, plus, it was recording the changesets in the system database.

The SQL statements are all bundled in a few files, so I began splitting them by database, and inserting --changeset entries every time I saw a new USE [foo]

Everything was looking good, and I thought that was how I had to go about it. That gives me a changelog per database, which is probably ideal if you were starting clean.

However, I accidentally missed a statement in the Logging database that inserted records into the App database; so, I had duplicate insert statements in both databases, but the insert explicitly said:

INSERT INTO [app].[dbo].[tableA] values ('1', 'one')

So, when I ran update against both databases, it succeed for App but failed on Logging. The interesting thing though is that if I put in a DELETE first under Logging, it then succeeded, despite the URL pointing to the Logging database instead.

That surprised me a bit, but now makes me wonder if I couldn't just list the Logging database in the URL and leave all of the changes together; the App change sets and the Logging change sets would be recorded against only the Logging DB.

I know that could prevent splitting them down the road, but it seems like it would be much easier to implement in the beginning, given that all of the SQL statements are already mixed.

Answer 1

I'd say the answer is "It Depends". My general advice is that you should use a single databasechangelog per application although if you have a lot of independent modules it often makes sense to break it up by modules. The modules need to be completely independent, though, with no cross-object references.

In your case, it sounds like you have separate independent modules, but unless you have a good reason it is probably easiest and less error prone to still have a single databasechangelog table that manages what has been applied to both schemas/databases. It is just a trade-off in modularity vs. simplicity.

With a single changelog file and databasechangelog table, You are able to use the "catalogName" attribue on most operations to specify the database that they changes should be made in.

Liquibase uses just one connection, so using a single changelog table will allow you to only need to run liquibase once, but the user you connect as will need permissions to both databases.