Jacob Lewallen - All Comments

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

re: Projects in Visual Studio

Patrick Smacchia — Mon, 28 Apr 2008 16:00:42 GMT

> Do I have a group of classes that can be packaged and then later re-used?

I am very surprised that nobody mentionned the namsepaces. Project/assemblies are physical stuff and should never be used to just group some classes. Only physical reason can lead to new physical artefact (such as tiers that live on different machine separation, or interfaces for IoC).

> I want two things. I want something slightly lower on the hierarchy than a project - a sub-project.

Previously I wrote Project/Assemblies because VisualStudio enforces a one-to-one relationship between the two concepts and this is indeed very unfortunate. You won't solve this with .NET modules that are another physical concepts but more with a mapping between projects and namespaces.

Reflective Perspective - Chris Alcock » The Morning Brew #82

Reflective Perspective - Chris Alcock » The Morning Brew #82 — Mon, 28 Apr 2008 07:31:01 GMT

Pingback from Reflective Perspective - Chris Alcock » The Morning Brew #82

re: A First Look At Machine.Migrations

jlewallen — Sun, 27 Apr 2008 19:35:35 GMT

Oops, I am a total moron and accidentally deleted some comments when trying to nuke that spam. Here is what I nuked, sorry David.

> David Laribee said:

Cool.

I half wonder if migrations shouldn't refactor NH mappings as well. In a greenfield scenario where you've got a clean association of tables serving as entity and value object stores, why not?

> And then in reply to my 7:17pm comment:

I got the idea talking to Jeremy Miller about an internal DSL (fluent interface) for expressing NHibernate mappings. Pairing this idea with a sort of "conventional mapping" approach (where you don't have to express all that much mapping at all; it is inferred) got me wondering about why we're migrating our databases then modifying our mappings, especially (or exclusively) in a greenfield or highly-controlled, model-first scenario.

So now I return to the idea of why we don't maintain migrations as maps and why we don't treat maps as evolutionary. This style would seem possible given the whole object first mentality a lot of us are latched on to.

re: A First Look At Machine.Migrations

jlewallen — Sun, 27 Apr 2008 19:29:03 GMT

Andrew,

Machine.Migrations looks for individual files matching a regular expression and pulls the version number out then. It creates MigrationReference from that process. (I've included a link to the relevant source) Once it has decided which migrations to apply (based on those versions and the version in the database) they are then compiled (See MigrationRunner.CanMigrate) Each individual migration gets its own assembly. We never lose that original MigrationReference and so we know where to find each versions migration, etc...

svn2.assembla.com/.../MigrationFinder.cs

svn2.assembla.com/.../MigrationRunner.cs

re: A First Look At Machine.Migrations

Andrew Stewart — Sun, 27 Apr 2008 18:14:06 GMT

I'm just wondering how you got the version number from the filename? As a contributer to rikMigrations a similar framework I'm unaware of a way you can do this? We have used a migration attribrute on ours t get the same effect however it is code noise.

Cheers

Andy

re: A First Look At Machine.Migrations

Jacob — Sat, 26 Apr 2008 02:17:36 GMT

David,

I think you'd have to migrate your mappings and have that generate your schema migrations. Otherwise I'm not sure you could infer enough from the schema changes to adjust the mappings. Interesting idea though.

Whenever I start thinking about improving migrations in general I get frustrated. I just don't like migrations at all. I want my application to migrate itself when I publish.... I've had ideas on this but nothing worth implementing just yet, especially given our architecture.

re: Good Tools and ReSharper 4 EAP Thoughts

Martijn Burgers — Fri, 18 Apr 2008 08:27:14 GMT

@Eric Swann : I have exactly the same annoyances with the unittest runner 3.1 build for VS 2008. The main difference with the unit test runner for VS 2003 (i can only compare with vs 2003) is that the devenv.exe process uses far more cpu time while in VS 2003 this is almost idle. This results in my case in out of memory exceptions and slow gui response.

This is problem occurs probably due to the output a test creates. ReSharper renders the test output to an html control while the tests run and this can take significant amount of CPU time if there's a lot of output. In my case i have turned on the the 'Track Running Test' option and this improves the run slightly.

I've reported this to jetbrains and they will improve this in 4.0. They are planning to disable output at all when the

Output panel is hidden in the future versions, so that it will speed up the test runner more.

Laters,

Martijn

re: Good Tools and ReSharper 4 EAP Thoughts

Jacob — Thu, 17 Apr 2008 16:21:25 GMT

DeeJay: I'll have to look into Unleash It! Our deployment is done with msbuild+robocopy+TeamCity and I'd like to see what other options we have, especially with multiple web servers, etc...

Eric: My EAP has been pretty stable. I do see an occasional exception though, but it doesn't get in my way.

Jura: Great to hear on the Generate wizard and I will add that as a feature request. Thanks...

re: Good Tools and ReSharper 4 EAP Thoughts

Jura Gorohovsky — Thu, 17 Apr 2008 14:26:11 GMT

Hi Jacob,

1) There's currently no such setting in ReSharper that would allow you to use Import Symbol Completion as the default completion technique. However, you're welcome to create a new feature request in <a href="www.jetbrains.net/.../a> if you feel that's really important to you. Please set forth your reasons clearly - the more convincing your request is, the higher is the chance to see it implemented :)

2) As for the Generate wizard, we're planning to improve it considerably by the time R# 4.0 is released, and if you stay tuned for new EAP builds, chances are you're going to be able to take advantage of these improvements even sooner.

Happy coding!