What are the advantages of SolidBase over LiquidBase?

[Al]

Hi,

What is the rationale behind SolidBase? I'm considering using
LiquidBase but I'm not sure it's a perfect fit for our current
development and release processes so I'm seeing if there are
alternatives.

Thanks,

Al

[René de Bloois]

Hi Al,

Good Question. The most important advantages over LiquiBase are:

1. SolidBase actually manages the version of your database. There is a
single version number which exactly defines how your database looks
like. You create upgrade paths to get from one version to another.
Liquibase does it differently, LiquiBase works with a bunch of
unrelated changes, and it registers every applied change separately.
There is no easy way to see what the version of the database is. You
have to check every single change if it has been applied or not. Using
SolidBase it is easier for the application to check if the database
has the correct version.

2. LiquiBase fails when you are doing branches. For example, a
developer is doing work on a development branch (feature branch), and
he adds a change to the LiquiBase changelog. The change gets applied
to his database and the databases of anyone that is working on this
branch. After that, he switches to doing development on another
branch, a branch where this change does not exist. But LiquiBase does
not revert the change because it does not know about it. SolidBase
makes working with branches safer by defining dedicated paths between
development branches (so called switches or even downgrades). Or you
could leave them out, in which case developers can only go from branch
to branch by dropping all objects in the database. SolidBase gives an
error in that case because it does not see a path between the two
branches.

3. With SolidBase you use SQL, not XML. You can add anything you want
to the upgrade file, as long as it can be executed with JDBC. For
example, with Oracle you can even send a block of PL/SQL (an anonymous
procedure) which gets executed immediately.

4. The SolidBase upgrade file is intended to be maintained by 1 or 2
developers, the so called developer DBAs, those that are specialised
in this kind of thing, and are able to keep high standards for the
database.

5. Cleaning up the upgrade file is easier with SolidBase. After a
couple of months development, you may end up with 200 changes to your
database and you haven't even shipped the first version to the
customer yet (not all projects are like that, but my current project
is). You can decide to collapse multiple changes into one as long as
the resulting database is identical to the one before doing the
collapse. The intermediate versions that disappear are effectively
deprecated so you should make sure that there are no important
databases alive that have a version number that is being deprecated.

6. You can add plugins. You can create a jar file, add it to the
classpath and your plugin will be automatically found. For example,
you found a way to check if the version of Oracle is the right one.
You want all customers to use that version. You can build a plugin in
java that gives a message that the customer should upgrade the Oracle
software. After that, the upgrade can be restarted and it will
continue where it left off. Another example: you want to add a NOT
NULL column to a database table which already contains data. Sometimes
there is no way for SolidBase to know during the upgrade what values
should be inserted into that column. You can create a plugin where the
customer can manually specify the values for the column, maybe through
a Swing user interface, or an Excel spreadsheet. Of course, this is
not easy stuff, and is not really required when there is only one
database in production.

7. You can also execute SQL files outside version management. In my
current project I use that to import 50.000 records of testdata in
just 8 seconds with SolidBase's IMPORT statement.

Hope this helps deciding which tool to use in your project.

Regards,
René