Difference between storing a DBUnit file in version control and using Liquibase for Database Version control

version control

What is the difference between storing a DBUnit database-loadable xml file in version control, and using Liquibase for database version control?

I'm relatively familiar with DBUnit having used it in Matt Raible's Appfuse project, and I've used it for unit testing in projects based on Appfuse. It never crossed my mind before, but it would seem to me that it could also be used for Database version control.

Now Liquibase appears to be used for version control of a database, but I fail to see how another tool is needed for this when you can just pull database changes using DBUnit, and get your data with it as well (storing that file in version control to facilitate your db vcs needs.)

There must be a reason that both of these tools exist, but I can't understand what the difference in scope between them is, could someone please explain this to me?

Best Answer

Liquibase is different in that it is mainly focused on ensuring your database schema matches with your current code version. It is not intended to be a diff tool (see http://blog.liquibase.org/2007/06/the-problem-with-database-diffs.html) but instead is a way for you to describe the database changes you need made. Liquibase will track which changes have been made to a given database and apply ones that haven't each time it is ran.

Think of liquibase like what is stored in a version control system: a series of patches that can be applied one after another to get from version a to version b. You just need to hand create those patches rather than have them generated by diff like traditional version control systems because with data, how the data changes is as important as what it looks like in the end.