How to Handle Manual Changes?

1

If we are currently working with Liquibase to database automation how to handle manual changes?

Currently I’m doing schema changes with creating changelog file and applying it. But what if some other do changes directly to the database without using changelog file at the same time when someone doing changes? Do liquibase track those actions?

2

Hello @nikeshi ,

Could you please elaborate your use case or the doubt you have. This will help community user to understand the problem and provide better solution.

Thanks,
Rakhi Agrawal

1 Like
3

For a example:
I added a column to the table directly in the database. Is there way to track that I did schema change?

4

Ideally, once you begin using Liquibase no one would make changes to your schema outside of Liquibase. But if they do I recommend the following:

  1. Code the same change into a Liquibase changelog
  2. Execute one of these Liquibase commands to record the new changeset into the databasechangelog table (makes it look like Liquibase did execute the changeset):
1 Like
5

One thing you can do in that situation is to use the diffChangeLog command to capture the manual change into your changelog file, and then use the changelog sync command as mentioned below to show that the change in the changelog file has been applied to that database instance.

1 Like
6

The proposed solution makes sense as long as you know that change. Let’s enlarge the example with someone else made 100 changes to the structure of the db.

I am very surprised that this tool which poses as DevOps for DBs does not consider this workflow. Most or all database intensive projects involve applying changes directly to the database. As a Database Developer, that’s what you do with your Toad/pgAdmin/etc. Please consider a way to compare the changelog to the db (currently the diffChangeLog compares a db vs another db, but that’s not the only comparison required).

7

I would argue that credentials should not be provided to developers, so they can no longer make changes directly to the database via Toad/pgAdmin/etc. DevOps tools should be the only path.

8

… lol

Tools like that are meant to help developers develop so not a chance.

9

If you are talking about allowing developers to make schema changes in a development databases, then fine. But anywhere other than dev should be restricted. This limits/eliminates the problem you are raising.

That being said, we’ve found that starting with Liquibase even in dev makes better sense and streamlines the overall devops process. We have 100s of applications, with 1000s of database/schema targets in my company.

10

I think i found a way to use Liquibase for my desired workflow. Here goes, feedback and comments are welcomed.

Desired flow: as a developer, i have a local db which i am working on and working on means with tools such as Toad/pgAdmin/etc; so i create tables and other objects. I need Liquibase to help me with following:
1/ document in SQL the changes which I am making in Toad/pgAdmin/etc; this code can be pushed to git
2/ help push [incremental] changes to an remote db (which serves as an integration db/environment)

To get this workflow to work, you basically need to create your remote integration db as the target/main one, and your local one, as the reference one (in Liquibase terms, configured in .properties file). As such, when you apply say 100 changes locally, you then do diff-changelog and you get these 100 changes documented and APPENDED to your change log; there is a small but, you just need to to delete the newly created line with this content “-- liquibase formatted sql” which is added each time diff-changelog is issued (i am assuming this is a bug). Once this is done, you can issue update command and push these 100 changes to your integration remote db.