Jacob Lewallen - All Comments

Machine.Migrations changes

Aaron Jensen — Sat, 24 Oct 2009 21:56:52 GMT

Jacob first introduced Machine.Migrations over a year ago. Since then, it's been a solid part of

Machine.Migrations: Version Tracking for Database Schemas

Bryan Czapp — Sat, 07 Mar 2009 13:41:10 GMT

Machine.Migrations: Version Tracking for Database Schemas

Are Database Migration Frameworks Worth the Effort?

Eden Ridgway's Blog — Sat, 03 Jan 2009 11:52:23 GMT

Are Database Migration Frameworks Worth the Effort?

Projects In Visual Studio

DotNetKicks.com — Thu, 17 Jul 2008 17:53:55 GMT

You've been kicked (a good thing) - Trackback from DotNetKicks.com

re: A First Look At Machine.Migrations

Mike — Tue, 01 Jul 2008 21:30:51 GMT

Hi,

I have two questions:

1. Where can I find a download for Machine.Migrations?

2. How does it compare to SubSonic Migrations and Migrator.Net?

Thanks for the introduction!

A First Look At Machine.Migrations [ CodeBetter ]

A First Look At Machine.Migrations [ CodeBetter ] — Wed, 18 Jun 2008 14:18:26 GMT

Pingback from A First Look At Machine.Migrations [ CodeBetter ]

re: A First Look At Machine.Migrations

aaronjensen — Fri, 30 May 2008 19:15:09 GMT

Why does Machine.Core need to reference NAnt.Core? We should probably put build tasks in a different assembly if the assemblies they need to reference won't be signed. Disabling signing is not an option.

That said, I know hammett is also working on a nant task, so we should probably get one of your implementations in so people don't have to do it on their own :)

Please send me your patch to aaronzjensen at gmailz.com (remove the z's)

re: A First Look At Machine.Migrations

Germán Schuager — Fri, 30 May 2008 14:55:03 GMT

Hi, I've been experimenting with an addition to Machine.Migrations to make it available as a NAnt task.

One of the problems I've found along the way is that I Machine.Core is needed to reference NAnt.Core which is not signed, so in order to continue I've had to disable the signing on the resulting assemblies.

I can submit a patch if you are interested.

Zen and the art of Castle maintenance » Blog Archive » Machine.Migrations is freaking sweet

Thu, 22 May 2008 20:15:31 GMT

Pingback from Zen and the art of Castle maintenance » Blog Archive » Machine.Migrations is freaking sweet

re: A First Look At Machine.Migrations

Colin Jack — Tue, 29 Apr 2008 18:23:59 GMT

Ta for replying.

"Error prone because we do use NH and the SQL tends to be pretty complex in inheritance mapped hierarchies."

Yeah that's definitely true, will be interested in reading more about the approach that builds on the NHibernate/entities.

re: A First Look At Machine.Migrations

jlewallen — Tue, 29 Apr 2008 16:15:32 GMT

Chris, absolutely, send it on over!

Colin,

Without knowing more about the particular system you're using I'm not sure I can offer up all of the pros and cons. If you're using just SQL change scripts the pros I can think of are you're far more resilient to changes. As I mentioned our particular approach doesn't do so well when we let data migrations sit around without being applied because you need to maintain them. And then you lose the ability to build your DB from scratch. Then again, using this approach gives you power. You can do lots of things in your migrations that would normally be very difficult or error prone in SQL. Error prone because we do use NH and the SQL tends to be pretty complex in inheritance mapped hierarchies.

We also run production copies of the DB in dev so we're more aware of the performance. This solves the problem with old data migrations that won't compile and us from having to create new blank databases. We run our tests against a light version of the database that is basically production with data purged.

I'm a big believer in tools being right for some and not necessarily right for others.

re: A First Look At Machine.Migrations

Chris Bilson — Tue, 29 Apr 2008 13:17:27 GMT

Hi Jacob,

I have been playing around with IronPython and since there is already visual studio integration for it and the syntax is so similar to boo, I figured it would be fun to add IPy support to Machine.Migrations.

I did that, and while the language is similar to boo, the API is completely different. Basically, instead of compiling a module, you ask the IPy engine for types defined in migrations scripts.

I have the implementation of a PythonMigrationFactory along with a test. I can submit a patch if you are interested in looking at it.

Until boo support for visual studio gets built, this is a simple way to get vs integration.

re: A First Look At Machine.Migrations

Colin Jack — Mon, 28 Apr 2008 20:29:17 GMT

Realized I have a few questions but first I should say that since I have little experience of the migration functionality in Rails this could be a dumb question...

Basically I wondered what would push you towards this approach versus normal change scripts? I'm just asking as we use manually created SQL files, they and the resulting DB are versioned so we could apply just the required updates but in general we just build the DB from scratch on dev machines.

Anyway I'm guessing that the main advantage of this sort of approach is when you go to the more complex model driven approaches (based on your NHibernate entities)?

re: A First Look At Machine.Migrations

Colin Jack — Mon, 28 Apr 2008 19:55:54 GMT

Very cool stuff, look forward to reading your future blog posts on it.

re: A First Look At Machine.Migrations

Andrew Stewart — Mon, 28 Apr 2008 18:40:19 GMT

Hi Jacob

Thanks for that, thats just cheating compiling it all together when you need it. ;o)

Cheers

Andy