Xebia

Blog Xebia France

J2EE, Agility and SOA

Review of the papers Xebia
Review of the papers Xebia
December 3rd, 2008
Print this ticket

Refactorisation of databases with Liquibase

To manage the modifications of a database is always a delicate matter, that it is during the development of an application, during the unit tests and even during deployment in production.
They notice a big number of difficulties, especially in plans Agile, where changes like data are frequent.
At present, few tools are available on the market and they seldom think of setting them up on our plans. They cross "houses" by solutions with all difficulties which it can procreate.

First of all, we will make a point on problems put down by the management of databases, then we will see how Liquibase, tools of Refactorisation, is possible help us to overcome them.
We will go on by the description of its characteristics and main functionality and by the different means to carry it out.
A small exercise to gain knowledge of this tool will come to conclude this ticket.

Problems put down by the management of databases

When a plan starts, they often wonder if it is necessary to instal a database by developer or a common base for all.
On plans of reduced size, a base can be enough and a person is indicated to centralise changes and to avoid so problems of redundancy, of disconnectedness, etc. But in that case, as soon as a change is performed, everybody must imperatively update the model object otherwise he runs the risk of not being able to any more throw application. Moreover, the games of tests of every developer can  t lescoper  what can make lose a lot of time.
On more important plans, it is preferable to have a base by developer, what causes other difficulties, such as reverberated them of changes from a developer to the other one or else a more laboured integration.
Following question also asks: how successive changes are going to be drawn? The most common rest to write a file of update SQL but it is not systematically made during developments and this lacks structure (in sense XML) and this no clean signification. For example, nothing allows fast to differentiate in a script, a code which applies the changes of the one who rollback (apart from comments!); or actions as "Renommer " are translated by DROP COLUMN / ADD COLUMN, what makes lose the sense of action.
This last question leads to settle others:

  • how versionner changes performed on the basis of data?
  • how to apply changes? Between developers, but also when they pass in integration, then in recipe, etc. For the moment, this stage takes of time, that it is upstream if they decide to packager changes correctly, or downstream when it is a question of unwinding scripts.

Here are in some sentences numerous met difficulties when they want to re-factorize a database.
Let us look currently at what a tool as Liquibase can make to accompany us in this delicate job.

Refactorisation of databases with Liquibase

Liquibase is a tool which can integrate with a plan (Ant, Maven, etc.) or launch in standalone fashion directly online of order (Jar).
His objective is to make easier modifications brought in a database. It is particularly practical in plans having adopted an Agile methodology, because changes are numerous, frequent and important.
The developer records in a file XML (changelogs.xml), the refactorisations different that he wants to perform (creation of new one banks on, renommage a field, insertion of data, etc.). Then, it is enough to throw Liquibase by giving him the parametres of connection at the root of data and at the root in base the file changelogs.xml. Liquibase applies these modifications and draws them in a table.
Changelogs files are versionn s in the administrator of sources, and considered to be any other resource of plan. Database is then completely included into the cycle of development.

After this short presentation of Liquibase, let us be interested in the main characteristics of this tool.

Characteristics and main functionality

Liquibase is Open Source broadcast under licence LGPL. This Open Source plan is active, the last version (1.8.1) went out in October, 2008 and its road map shows that he wants to go even farther. He supports a big number of databases (> 10) and offers 30 more than refactorisations possibles. And for some, he can even make a roll back (Ex: reappoint a column).
Changes can be regrouped in a changeset, what allows to keep a sense and a coherence to modifications.
It is also possible to carry changes out only under some conditions, or according to some profile of execution (useful for the games of tests for example).

It is possible to note also that Liquibase is not just "pointed  at the Refactorisation of database, he gives other fonctionnalit

Key words :, , , , , , ,

Tickets on the same topic:

You can follow answers accepted by this article thanks to the thread of comments.

4 answers to Refactorisation of databases with Liquibase

  • On December 3rd, 2008 in 18:41 (), Waddle said :

    Good morning,

    It is indeed about an interesting tool. However, to pass by XML, even with the compl tion of IDE, seems to me more verbose and more tiring.

    In the case of an unique base shared by all developers, the contribution of this type of tool seems to me very limited in comparison with a good use of the administrator of sources (after all, a SQL is only source of database): update of the file of creation of database, tagging of a version of the plan including the model therefore object and SQL. If it is a question only of economising a mail inviting teams to update sources

    In the case of a database by developer, interest is more significant, but this approach is really not very favourable and especially dangerous (shape of BDD, numerous versions on the post of development, numerous products, etc.) so in a personal capacity I have never set it up. As for the games of tests which "Telescoperaient" , if thereabouts you hear that the tests of some influence the tests of others, why simply not to be taken by a base hsql for tests? It allows besides testing the script of creation at the same time.

    To finish, I would say that a database evolves only occasionnelement during a plan, even in an agile plan. I hear thereabouts that she does not change every morning.

    I remain sceptical therefore, but very good article incidentally, as usual :-)

    has +

  • On December 3rd, 2008 in 19:45 (), Emmanuel said :

    Good morning,
    Thank you for this comment which launches debate.
    The solution " the simplest " is always a good solution. Most plans use scripts SQL and take out well.
    However, you should not see Liquibase as a tool only for the development and which carries out of SQL. He makes many more things: monitoring of modifications (author, date, etc.), rollback, generation of material, generation of diff. He can serve for deliveries in different environments, etc.

    As for the dangerosit of a base by developer, I agree enough, but this is obvious by instant.

    Personnelement, I prefer working with FICHIRES XML where with (fast unreadable) scripts SQL. Files XML are certainly more verbose, but his structure makes reading easier. Beacons which point code out of rollback, it is very practical. And it is easy to prove that the modif and its rollback were well written (unfortunately, it is not always case!).

    Of experience, databases evolve always during the cycle of a plan a lot. But if it is not case, Liquibase introduces of course less inter t.

    It is possible to claim also  to be another tool, to be a tool of surplus?  , but the advantage of Liquibase is that he is simple and not much invasif.
    He asks for a little of investment to take it well in hand, as all new tools, but behind, he really makes easier the management of database.

    Emmanuel.

  • December 3rd, 2008 in 20:20 (), pse said :

    This seems interesting indeed.

    To react to the previous comment:

    - if it is possible to work on a plan the model of data of which evolves in every version (addition of tables, columns). It is our case :-)

    - our scripts SQL in SVN are well managed, but the problems of patchs stay: if you change your diagramme, it is necessary you to write a patch for upgrader your bases. Therefore either you duplicate your changes SQL between the patch and the complete diagramme, either you use a tool capable of making a diff between 2 diagrammes, or you use a tool of this type to centralise updates in another format.

    To see.

  • On December 18th, 2008 in 0:41 (), Robert said :

    This terrifically makes me think of the script db:migrate which is found in Rails. In difference pres of format (encode ruby instead of XML), it is a question of describing different migrations (rajout of columns, tables, change of format, etc) of the BOULEVARD with the possibility of playing again, of coming back in arriere, etc a bit as Liquibase.

Review of the papers Xebia
Review of the papers Xebia


Defence Colis e - 10/12, avenue of The Ark
92419 Courbevoie Cedex

T l : +33 (0) 1 46 91 76 16
Fax : +33 (0) 1 46 91 88 00
E-mail : info@xebia.fr