-
Notifications
You must be signed in to change notification settings - Fork 245
Features
This describes both advantages and limitations of RH. You should understand both its strengths and weaknesses to understand if RH is something you can use in your organization.
RH supports more than just SQL Server and it is adding more items to that list all the time. RH supports SQLServer 2000-current (including express editions), Oracle, Access, MySQL, SQLite, and PostgreSQL!
RH 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. See ConfigurationOptions.
There is nothing new for you to learn. Start using the scripts you already know. And your DBAs already know.
RH is a sql migrations engine, not in itself a migrations framework. That means you can use any migrations framework you want as long as the framework can generate SQL Script files. This means that you can use NHibernate's Schema Create/Update (see RoundhouseRefreshDatabaseFNH), Entity Framework Migrations (working on Refresh Database package for that), Fluent Migrator, or any of the other code based migrations frameworks.
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 a TXT file containing the version, 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. See 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. See RoundhousEModes.
RH is environment aware, which means you can have environment specific scripts. If you have scripts or permissions scripts that are different for each environment you can give them a special name. See EnvironmentScripts.
RH is an easy choice 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 speeds up your development process. You can use RH with NHibernate to refresh your database without leaving Visual Studio! Entity Framework and FluentMigrator are planned for this feature as well. See RoundhouseRefreshDatabaseFNH.
RH runs on just the .NET framework. This means you don’t need SMO installed like some other migrators require.
RH still splits correctly when the GO keyword is in SQL files, which ADO.NET does not like. With Oracle, the rules shift a little, but RH still splits when necessary.
You can just download the bits of RoundhousE and start using it. No installation necessary.
It costs you nothing to use, the license is developer friendly (Apache 2.0). So you can use it with confidence at your place of business without worry that you haven't met some agreement.
Find a bug? Fix it and submit a path. Or let us know on the issues list. You want to discuss something about RH? Drop us a line on the mailing list
RH was originally built to meet the needs of SOx for the contributors. We found no other free tool at the time that could answer SOx auditing questions in the same way that RH can. When RH runs, it keeps track of exactly what was run in both the database and on the file system. It provides a log during execution and saves that log on the file system for later retrieval by auditors.
RH has many conventions, but the developers realize that not everyone is in the same situation. Therefore RH can meld to your expectations.
RH is set up to make DBAs life easier as well. If you have thousands of stored procedures, views, functions, you don't want to wait for a tool to run them all. RH only runs the files that have changed since the last time it ran. There is an override switch for this in case this doesn't meet your conventions.
RH does not support the concept of going down in migrations (yet).
Doing a real down is nearly impossible if you delete a column and need to bring it back. The best approach to a real "down" concept is to backup the database prior to running any migrations (if backups are possible). If things go wrong, you can just restore the backup.
Another alternative that we have also done in the past was to fix a bad script and rerun the migrator. Be aware this is still an up migration though.
Since RH is useful in every environment along the way, having the ability to test your scripts over and over again really reduces the possibility for errors and a necessity for down. That said, it does happen, and knowing what RH will/will not support is important.
RH does things a different way that will feel very natural during development so you don't miss the idea of a down migration. See RoundhousEModes and Refresh Database.
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#, and Entity Framework Code Migrations.
RH only migrates to the latest version set of the sql scripts you are giving it at run time. If you are using the output of a build or source, you can get to specific versions by deploying an older build.
RH does not have a GUI tool (yet). All of it's runs are done with the executable or some run you kick off with the embeddable DLL. Most people that use the tool do not find this a limitation as batch files are provided as examples.
RH is not a db modeling tool. You can use your db modeling tool to generate scripts and then use RH to migrate the database though. Remember that RH is only as good as those change scripts that are generated, though.
RH was featured in the book Continuous Integration in .NET. This is really just for cool points.