addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

The Boston MySQL Meetup Group Message Board › My comments about our yesterday meeting

My comments about our yesterday meeting

Jacob N.
user 2421302
Needham Heights, MA
Post #: 43

I am writing these comments to help people who came to our yesterday meeting to avoid confusion which I think has happened at the end of my yesterday presentation. Some people who attended the yesterday said that LiquiBase tool is exactly the same as the CatalogVersion tool which I presented. Those remarks created some confusion why I wrote the tool when exactly the same tool already exists.

I read about LiquiBase tool about a year ago. Of course, at the meeting it was not easy for me to remember any specific points, so I could not explain how it differs from my tool. However, once I looked at their documentation, it was very clear how different they are. While both are used for Database Change Management (the same could be said about such tool like DB Ghost by Innovartis, or SQL Compare by Red Gate, or DbMaestro by TeamWork or many other similar tools from other companies), their design and implementation, and consequently the set of features are drastically distinct.

Of course, from very general point of view they are all the same, because their purpose is the same. However, from this point of view Oracle, MySQL and SQL Server are also the same databases, because they have the same purpose. I don't think that for people who come to our meetings such a general view is very interesting.

LiquiBase is significantly different from CatalogVersion. I did read about it before I implemented my tool and I thought that LiquiBase design is not the best suited for solving our problem. The central piece of their design is Database Change Log - XML file containing the differences between repository versions. You can run the tool and apply this log to another database to create another version. In a way it is quite similar to what Subversion version system does.

While Database Change Log is legitimate way to record the differences, I would prefer not to have additional artifacts to manage independently in addition to SQL scripts. I think the scripts themselves are quite effective in managing the difference between databases' versions. You don't need another large file written in XML format - SQL is powerful enough and does not need additional language to make it even more powerful.

There are other important differences. One of the CatalogVersion's fundamental ideas is a connection between the state of the source code and the state of the database. It is clearly recorded in the table and enforced by using foreign keys. This is especially important in case when the same database state corresponds to multiple states of the source code. This functionality is very different from what I found in LiquiBase.

I am not trying to say that CatalogVersion is better or worse than LiquiBase. My point is that they are very different in design and functionality. In my opinion to say that they are the same is a gross oversimplification. I hope that these comments will help to make more clear why I wrote CatalogVersion tool in spite of the fact that "the same" LiquiBase tool already exists.

Jacob Nikom

Powered by mvnForum

Our Sponsors

  • Technocation, Inc.

    Video camera, host video files, meetup fees. They are non-profit.

  • Oracle, Inc.

    Oracle develops the MySQL database core and offers support and training.

  • Akiban Technologies

    Has a new table grouping technology as a denormalization alternative.

  • Tokutek

    TokuDB is a drop-in replacement for InnoDB that scales MySQL®.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy