Comments on: Database Continuous Integration in .NET

By: Database Continuous Integration with DBTracer « DBTracer

Database Continuous Integration with DBTracer « DBTracer — Mon, 01 Feb 2010 20:34:14 +0000

[...] no such tool existed that would have been acceptable. Hence, we inspired by Alexander Kleshchevnikov and wrote our own tool DBTracer. Currently it is in experimental phase for public. We use it [...]

By: Anton Gogolev

Anton Gogolev — Fri, 22 Jan 2010 09:05:33 +0000

Check out Wizardby: http://code.google.com/p/octalforty-wizardby/

It has a special DSL for expressing migrations and a lot of nice features as well.

By: Cameron Singe

Cameron Singe — Tue, 26 Aug 2008 04:11:46 +0000

Hey, thanks for this, I’ve written something like this a few times. My concern with the Migrator .net, is the running the build function on the production server, at least with managed sql scripts its fairly straight forward to deploy even on managed/shared servers

By: sissi

sissi — Tue, 08 Apr 2008 08:38:18 +0000

By: Alexander Kleshchevnikov

Alexander Kleshchevnikov — Tue, 25 Mar 2008 15:14:03 +0000

Personally, I think that “migrator approach” that comes from RoR is suitable for projects where data access layer is responsible for creating data access objects itself. So you do not care about a bunch of CRUD procedures, you do not need to create other database structures to store data and you do not need to create lots of T-SQL code. This all will be maintained by DAL methods. So C# code to make upgrade and downgrade will be clean and simple.

In other case if you create manully all the database schema it’s much easier to manage it in SQL update scripts.

I would choose Migrator.NET if I used Castle ActiveRecord library for DAL. It fits for this purpose for sure.

By: Maxim Tihobrazov

Maxim Tihobrazov — Tue, 25 Mar 2008 11:56:37 +0000

DbRefactor allows adding columns, for example:

AddInt(“TableName”, “ColumnName”); // Adds an integer column to TableName

and also you still can construct complicated SQL queries if you need – DbRefactor allows to execute plain sql

But It is complicated task to maintain database with DbRefactor if project contains a lot of stored procedures

By: Alexander Kleshchevnikov

Alexander Kleshchevnikov — Mon, 24 Mar 2008 22:22:05 +0000

Hi Dima! Nice to see you here. Migrater.NET looks nice. One question though. Most of the projects especially production ones have data in the databases and CREATE and DROP table aren’t the proper methods of database updates because the data stored in the tables will be lost. For example, if I need to add a new column I usually create a new change script with T-SQL:

ALTER TABLE [TableName] ADD [ColumnName] [ColumnDeclarations]

Or, for instance, I need to make some kind of operation through out the table and cursor is required so T-SQL will be more complicated in this case. Not sure that C# style is more suitable than standart T-SQL.

What do you think about all this?

By: Dima Pasko

Dima Pasko — Mon, 24 Mar 2008 21:07:44 +0000

I also recommend Migrator.NET (http://code.google.com/p/migratordotnet/wiki/Links) or DbRefactor(http://code.google.com/p/dbrefactor/ – modified version of Migrator.NET).

These products are based on Ruby On Rails – Migrator idea (http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)

You don’t need to write any SQL code – all will be in C#