More often then not it would blow up and so I would spend the first 1/2 hour every time I worked on the project getting things to work again. Well no more!
FluentMigrator is based on Ruby Migrations, with a fairly simple syntax. The db classes have the attribute [Migration()] that specifies the version, and inherit from the Migration class, and override the two methods Up and Down.
Migrating Up and DownThe Reason for the Up and Down methods is very simple; if the version your migrating to is higher then the version of this class it executes the code in the Up method and if the version is lower then the code in the Down method executes. Basically whatever you do in the Up is undone in the Down.
Setting The Version NumberSomething else you may have noticed is in the Migration tag the version number is fairly large, to make versioning easier on a team, I’m not using consecutive numbers but the date and time(using 24 hour time) of when the I added this class, so the the example class I created was on 6/24/2011 at 23:24 10. The current version number is also stored in the DB, making it very simple to see what DB version you’re on, this can come in handy if your code is based on a specific DB version you can do a simple check to see if you have the correct DB version.
Keeping version iterations smallJust like when creating a business logic class, you should follow the single responsibility principal, and have each class do only one thing, this may mean having a lot of classes but on the other side it will make it a lot easier to keep track of what each version added, modified, or removed.
Adding stuff to the Data BaseUsing the Fluent api allows you to very smoothly add tables, columns etc. in a very readable way. If you look at the Up method in the above example you can see how easy it is to add a table with columns. This makes it very easy to add your own extension methods to short had it even further. Here is an example for creating an identity column and a table with time stamps:
But the api doesn't have everything you need so you have the option of adding in strait sql using Execute.Sql(). like this example:
also you can call sql files like this:
Adding DataThe next step is to add some data. This could be some sample data for development, a larger dataset for QA, QA data for a specific type of customer, or base data for production. By adding profiles you can abstract away what data you want to add for specific function. This is not where you add data for things the should be constant, things like lookup tables should be handled by a versioned migration class. Here is an example of a profile class:
Just like a Version class it inherits from the Migration class and has an up and a down method, this way when you add one profile it will remove the other profiles.
Deploying/Migrating Your Data BaseDeploying or Migrating your data can be done with a console app or with a build runner like MSBuild, nAnt, or Rake making it easy to integrate into your existing build process. For this example we are going to use nAnt. Here is an example nAnt build file:
To use FluentMigrator with nAnt you use loadtask to specify the FluentMigrator.dll then you add a migrate task in your target. Your migrate task will need to have the following properties:
- database – this specifies the type of DB (sql, oracle, sqllight, mysql, etc.)
- connection – this specifies the DataBase your going to connect to and with what permissions
- namespace – this is the application namespace your going to run allowing you to migrate multiple DB in the same project
- target – this is the .Dll you’re calling to migrate from
- Profile – this is what profile your loading
- task(optional) – this is how you specify what version you want to build, or if you want to roll back, etc.
Then to run your migration simply run NAnt.exe with the name of your build file something like:
A full explanation of using nAnt is a little out of scope for this blog post so if you want more info on nAnt see nAnt Help Page.
As always here is a sample project using this.