Making LB more "Refactoring-oriented"

Hi all,

I have been using Liquibase on a few projects recently and have found it to be a very useful tool. Congrats to all involved - it fills a very important role in the development process which has been sorely lacking up until now.

The question I have is regarding the overall direction of the project.

At present, LB is oriented towards db change management, a job it does very well. It has really helped me to manage db changes made by my team and has greatly simplified the release process for our db-intensive applications.

However in the future I see the direction of tools like this as being more oriented towards making db refactoring more like the “usual” code refactoring operations we are all used to. In other words, more of a high-level view where the tool helps the developer to state their intent but then takes care of the nitty-gritty details for them. In this view a “refactoring” should take into account dependencies between database objects and make sure that a refactoring begins and ends with the whole database in a consistent state.

As a simple example, everyone’s favourite the “rename column” operation should:

  • rename the column (obviously)
  • refactor stored procedures, triggers, views, object types, etc. which use that column to use the new name
  • possibly even allow the declaritive specification of constraint naming conventions so that constraints on the column are renamed.
  • rename foreign keys referring to that column if needed using the above naming conventions
  • etc…

For other refactorings, like changing datatypes, we might apply standard data-cleaning operations which the refactoring might need (eg in Oracle, changing a column datatype from CHAR to VARCHAR2 might necessitate a TRIM() operation).

Obviously not a small job, but the result of all this would be a tool which would make db development a LOT less painful… (I know, I’ve been there many times!)

Are there any plans to take Liquibase in this kind of direction?

Thanks for an awesome tool.


I’ve thought about it, but much of those extensive “refactorings” require run time knowledge of the database at the time you want to make the change, which we try to avoid in our liquibase change tags so they can run in updateSQL mode. 

I made a proof of concept “Liquibase IDE” at one point with the idea that the IDE would do those database inspections and generate all the required liquibase changeSets.  It proved too much to maintain myself along with the liquibase core itself, and so the project has not been updated for a very long time.  It is something I think would be a great project, and I would like to get back to at some point.


Originally posted by: Nathan
I made a proof of concept "Liquibase IDE" at one point with the idea that the IDE would do those database inspections and generate all the required liquibase changeSets.

That sounds like a sensible way to tackle it - retaining the existing LB change tags as the low-level operations and allow the IDE to handle grouping them together into refactorings. This would make a very powerful combination.

I would like to help with the IDE development … what is the current state of it?


Currently it’s in the “need to start from scratch” phase :)  The existing code is based on an old version of liquibase and an old version of eclipse.  Both have changed enough that there is not a lot of reusable code, I don’t think. 

I have a lot of thought into different approaches that can be taken, if you’d like you can start a new thread (so the discussion can be found and linked to better) and we can talk through them.  The biggest thing I would want is someone or a group of people who feel they can support it long-term.  I felt bad having to abandon the original liquibase IDE codebase due to my inability to support it since it left people using it without an improving product.  It is definitely something that would be very great to have, and something I have kept in mind supporting in the architecture of liquibase.