Sites

“Because everyone wants to kick their database, but sometimes kicking your database is a good thing!”

Many would not argue that you should version your code, and few would argue against versioning your code in a way that can lead back to a specific point in source control history. However, most people don’t really think of doing the same thing with your database. That’s where RoundhousE (RH) comes in.

I have been working on RH for over two years now and people always wander what it is, why and what sets it apart from other migrators. We set out to make a smart tool for migrations that came somewhat close to Ruby’s ActiveRecord Migrations without going the code migrations route (yet). Hopefully this introduction will help you understand why it is different and whether it’s something that is in line with your needs.

What is RoundhousE?

RoundhousE (http://projectroundhouse.org) is a database migrator that uses plain old SQL Scripts to transition a database from one version to another. RoundhousE currently works with Oracle, SQL Server (2000/2005/2008/Express), Access, MySQL, and soon SQLite and PostgreSQL. It comes in the form of a tool, MSBuild, and an embeddable DLL. While someone is working on a GUI, there is no visual tool at the current time.

What sets RoundhousE apart from other migrators?

It subscribes to the idea of convention over configuration, which means you can pass the migrator very few configuration options to get it to work (rh.exe /d dbname), but pass as many options as necessary to meet your conventions. Say you don’t like the tables or folder names that RH uses, you can override those to whatever you want.

RH versions the database how you want it versioned. You can supply it with a DLL path for it to pull the file version from. You can give it an XML file and XPath, or you can use the highest script number in the up folder. You can also just use a sequence based (non-global) form of passive versioning. https://github.com/chucknorris/roundhouse/wiki/Versioning

RH believes in low maintenance and keeping good clean history in your source control. This means that you don’t lump everything into one folder, you put your anytime scripts (views/functions/stored procedures/etc) into their own folders and track history as you go. RH is smart enough to only run these if they are new/different from the current existing scripts in the database.

RH has three modes of operation. Normal, DropCreate, and Restore. Notice none of those are Create like you may see in other migrators. If the intent in the end is to have a database ready to go, why would you want to have to make a step to specify that you want to create the database? RH is smart enough to realize that the database doesn’t exist and it creates it (unless you pass a switch explicitly telling it not to). Normal is just the migration as it is. DropCreate is used during development when you want to continually change the same scripts prior to production. Restore is used when you switch to maintenance mode and want to change the same maintenance script. https://github.com/chucknorris/roundhouse/wiki/RoundhousEModes

RH is an easy to start using on legacy databases. You just take your old DDL/DML scripts and move them into a special folder that RH will only evaluate/run when it is creating a database (say on a new developers machine). You can arrange existing scripts into RH default folders or point RH to the existing folder types. RH splits scripts with the GO batch terminator in them.

RH runs on just the .NET framework. This means you don’t need SMO installed like some other migrators require.

While there are probably other features I haven’t mentioned, keep in mind that RH is not a code migrator (yet). If you are looking for a code migrator, there are quite a few good tools out there, including FluentMigrator and Mig#. Entity Framework Code Migrations is really starting to shape up as well (Seriously! Although EF only works for SQL Server).