There's a new release of RikMigrations available. This includes a lot of bug fixes from the original release and is the first since the development team expanded.

Big thanks to Andy Stewart in particular who has pushed the release out the door and is actively working on more improvements, particularly cleaning up my original messy code.

This also marks the official move of the codebase from CodePlex to Google Code. This change is mainly to get around problems with CodePlex's source control.

RikMigrations has started rolling again recently. It appears some posts on the alt.net mailing list prompted a few people to check it out and even better some have signed on to contribute as well. This prompted me to commit the changes I've made in the last few months (I'd been meaning to do it but had been lazy).

There's already the start of an msbuild task for RikMigrations and rumblings of a NANT one as well. Plus, a nice little tweak to use generics to define column types so you can do this:

t.AddColumn<int>("ID"); 

And there's also discussion starting around adding some ability to populate the database with initial values in migrations as well (https://www.codeplex.com/Thread/View.aspx?ProjectName=RikMigrations&ThreadId=24868)

PS. For the non-Australians out there the title refers to a famous Australian poem.

RikMigrations includes support for generating an initial migration from an existing database. Currently this only supports SQL Server databases. The feature was included in the initial release, but hadn't had much testing. Since then I've tested it on a database at work and confirmed it's working correctly (at least to some extent). The migration generator attempts to ensure tables are created in the correct order, but this feature was hacked in and needs improving. In doesn't support circular dependencies so don't even try.

The generator only supports generating in C# at the moment, however it uses CodeDom so other support for other languages is simple to add and a quick hack of the code will provide a version for your favourite language. 

To generate a migration from a database use the following command line:

RikMigrations auto -s:(local) -db:Test -f:Migration.cs 

You can also add the "-sf" flag to write each table into a separate class, but make sure you include a "{0}" in the filename to indicate where to place the name of the table.

I've just added support for SQLite to RikMigrations. This was done mainly because I use SQLite to store data in RikPVR and I needed to expand the schema. I tossed up whether to go with the embedded sql scripts like I have been doing or put in the time to add support to RikMigrations so I could use it. Eventually I decided it would be worth the work of adding to RikMigrations, if only to test how well it would support alternate database providers.

As expected, I had to refactor the code to support the change - alternate database providers wasn't in the original RikMigrations design, though I had already started refactoring towards a provider pattern. However, the changes were actually fairly minimal. I encourage others to sign up and start adding support for other engines.

Unfortunately, SQLite is a bit limited in some areas so not all features are supported. The biggest one is probably the inability to drop columns. There are workarounds for this in SQLite which I may look in to, but for the moment it will just throw an exception. Other ones I've run into is that you don't seem to be able to add columns with PRIMARY KEY or UNIQUE constraints on them once the table is created, but they work fine if they're added during the initial table construction.

In other news I've added a couple of extra pages to the RikMigrations doco. I'll keep adding to that bit by bit but if you have any specific questions drop me a comment or an email.

Finally, here's a quick bit of code in the meantime to show how to use SQLite instead of SQL Server. (This is only for programmatic access, I haven't added the command line interface yet)

DbProvider.DefaultConnectionString = @"Data Source=D:/TestDB.db";
MigrationManager.UpgradeMax(typeof(Joe1).Assembly, typeof(SqliteProvider));

The actual migrations stay exactly the same, except you may run into the limitations I mentioned earlier. I'll try to document them somewhere.

Over the last couple of weeks I've been working on a migrations framework for .NET called RikMigrations. There's a couple of existing frameworks but they're mostly integrated in other large projects like SubSonic or didn't quite fit my needs/wants.

RikMigrations is currently relatively small and simple, but I am releasing it under a BSD license on CodePlex so others can jump on board and build it up. Check out the project homepage at http://www.rikware.com/RikMigrations.html to find out more, including a simple tutorial demonstrating its use.