Machine.Migrations is freaking sweet

May 22nd, 2008

Update: patch is here, but nevertheless it was applied already.

First of all, yes, I’m a Family Guy’s fan, if you haven’t noticed yet.

To dig into Machine.Migrations has been on my to-do list for a while. After another error due to a missing schema on one of our projects, I moved it to a higher priority. Jacob’s introduction might be a good start, but really haven’t done it for me. So I grabbed the source and started to navigate.

Sure, I have some nitpicks about it, but overall it’s a beautiful piece of code. SoC nicely applied.

My requirements, however, are a bit different. I dont want my clients running migrations tasks, I want my project automatically updating the schema to reflect the latest model. As the project is modular, each module has its own schema version. So instead of inspecting the file system, I’d inspect assemblies. Versions wont come from file names, but from a class name from an attribute.

Twenty-minutes later I got it changed to support that, basically adding new implementation for two services.

Then I started to convert my old migration scheme (rudimentary) to the 001 migration for one of my modules. Something like:

Schema.AddTable("Company",
                new Column[]
                    {
                        new Column("Id", typeof(int), 8, true),
                        new Column("Name", typeof(string), 20), 
                    });

Schema.AddTable("Project",
                new Column[]
                    {
                        new Column("Id", typeof(int), 8, true),
                        new Column("Name", typeof(string), 20), 
                        new Column("Description", typeof(string), 20), 
                        new Column("Url", typeof(string), 20), 
                        new Column("CompanyID", typeof(int)), 
                        new Column("`Key`", typeof(string), 12), 
                    });
Schema.AddForiegnKeyConstraint("Project", "FKProject_Company", "CompanyID", "Company", "Id");

Schema.AddTable("User",
                new Column[]
                    {
                        new Column("Id", typeof(int), 8, true),
                        new Column("UserName", typeof(string), 30), 
                        new Column("Email", typeof(string), 20), 
                        new Column("FullName", typeof(string), 20), 
                        new Column("Password", typeof(int)), 
                        new Column("`Key`", typeof(string), 12), 
                    });

Ok, not cool. Too many strings, too error prone. I’m a firm believer that software can be made smart and help you where it’s possible.

So I changed it to

SchemaBuilder builder = new SchemaBuilder(Schema);

TableBuilder company = builder.AddTable("Company", 
        Columns.PrimaryKey<int>("Id").Identity(),
        Columns.Simple<string>("Name", 25)
    );

builder.AddTable("Project",
        Columns.PrimaryKey<int>("Id").Identity(),
        Columns.Simple<string>("Name", 25),
        Columns.ForeignKey("CompanyID", company)
    );

builder.AddTable("User",
        Columns.PrimaryKey<int>("Id").Identity(),
        Columns.Simple<string>("`Key`", 15).MakeUnique(),
        Columns.Simple<string>("Name", 25),
        Columns.ForeignKey("CompanyID", company)
    );

Let me know if you like it, so I can make the patch file available.

Categories: General | Top Of Page | 12 Comments » |

12 Responses to “Machine.Migrations is freaking sweet”

Doug Mayer Says:

This is very cool. Machine has been on my to-look-at-list for a while now. :-/ I like the changes here to keep from repeating the table names, etc as strings.

Conrad Says:

This looks great. Not having string all over the places is a very good idea.

Sean Chambers Says:

I need to look at this migration framework as well. I have been playing with Migrator.NET which is a port of Marc-Andre’s long since dead open source project. A user placed it on google code and there are a handful of us that play with it. The one thing that I like about Migrator.Net is that it supports multiple different converters to MySql, Postgre, MsSql and Oracle. Not sure if Machine.Migrations does that but the syntax above is very similar to migrator.net. I have to take a look at it for sure.

Dru Says:

I like your additions. A patch would be nice.

BenL Says:

Dude, patch patch patch! I’ve been using the old migration format for a while now, the fluent stuff you’re introducing is something I was intending on addressing myself. You’ve saved me a job!

Sean Chambers Says:

After grokking it for a little while the SchemaProvider classes are pretty basic. If I have time over the weekend I’ll write a MySql schema provider. That would be the last thing I would need to use it.

Ivan Says:

Where i can get demo project, solution or some peache of code illustrated this approach?

Vlad Says:

+1 for the patch.

Chris Patterson Says:

The syntax is much cleaner than the original, I like it.

Make it so — Machine.* is looking like a nice framework worth more investigation.

Zen and the art of Castle maintenance » Blog Archive » Migrations patch Says:

[...] migration class, as you would need to perform operations on the same transaction – Introduced the SchemaBuilder – Added support for unique keys (still need to support Defaults, [...]

Brett Veenstra Says:

+1 for the patch

Migration.Net en Unit Testing at Espacio de Dario Quintana Says:

[...] este post de Hammet, descubrí Migration.Net, y luego en este post de Ben quien nos deja una buena comparación sobre [...]

Leave a Reply