We have started to use liquibase internally and found it quite good so far, with some minor issues I will not detail here but that we might want to provide a patch for.
Our product supports 2 RDBMS, Sybase and Oracle, which have somewhat different capabilities and quirks. We try to handle changesets as rdbms-agnostically as possible, but for some cases we need to be more specific. We do this using context information that are applied using 2 techniques:
- Define rdbms-dependent variables that will be interpolated and replaced within changesets according to the actual RDBMS used. This is mostly useful to handle specific types,
- Define rdbms-dependent whole changes.
While this is not the standard use case, we sometimes need to migrate a DB from one system to another and of course this is where troubles start:
- Hash stored within DBCHANGELOG tables are invalidated when moving the DBCHANGELOG table from one rdbms to another as the variables' values change,
- DB can easily get corrupted, or migration fails, when liquibase will try to apply changes that have not been previously applied because they were not related to the source rdbms. Those changes could be applied in an untimely manner.
In particular, we do not know how to handle correctly sequences. In Sybase, sequential unique ids should be handled using identity attribute on column whereas in Oracle a specific Sequence object should be created then later used to retrieve unique ids. Historically we have been using some custom code to handle incremental sequences uniformly across databases, but as we are moving towards standardized RDBMS access through JPA, we would like to make things more uniform.
Assuming we are not the only people to handle multiple databases, I would be interested to know what best practices/advices/strategies other people use to handle this case (apart from the obvious “don’t do it” :-)).
Thanks in advance,