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.
cheers,
Anthony