Well, here it is! The release you all were waiting for, the one that finally gives migration support to Mack! That’s right, now whether you use ActiveRecord or DataMapper, you can use the familiar rake task ‘db:migrate’ to run your migrations. Yippie! The scaffold generator will also generate a migration for you, assuming you have ORM support enabled.

There’s still some work to go on this, like the ability to pass in command line args to the task to build the full migration for you, but it’s a start! It’s now pretty easy to get your app going.

Also in this release is a rewrite of the distributed routing functionality. It’s now been rewritten to use Rinda. This is going to be the standard for all the distributed functionality that will be coming Mack over the next couple of months. As more functionality lke this is developed, the more it will be wrapped in nice, easy to use APIs.

There’s also been some tidying up here in there in the code tree. For example, new applications don’t get generated with a boot.rb file. Looking at it, there’s really no need for it, since everything is done with Rake tasks.

Overall, I’m very happy with the release, and I feel that this release definitely makes Mack a VERY useable framework because of the migration support. Enjoy!

Changelog:

• Removed boot.rb file. It was unnecessary.
• When a new Mack application is generated the Rakefile that gets generated is stamped with the Mack gem version used to create it. This ties the project to that gem. This can, of course, be upgraded as new Mack gems come out, but it’s a good way of tying your app to a specific revision of Mack.
• Added support for migrations for both ActiveRecord and DataMapper. DataMapper migration support requires DataMapper 0.3.0 gem. Please keep in mind, though, that DataMapper 0.3.0 has a serious bug in it, which may prevent you from using it. Please see http://www.mackframework.com/2008/04/09/horrible-bug-in-datamapper-030/ for more information.
• Rewrote distributed routing support to use Rinda inside of plain old DRb. This makes for an almost zero configuration usage.
• Added: mack_ring_server binary to start a Rinda ring server for use with distributed routing.
• Sqlite3 is now the default database for Mack applications configured with ORM support.
• Added a test helper method, rake_task, to aid in the testing of Rake tasks.
• Added: rake generate:migration name=<migration_name>
• Added: rake db:migrate
• Added: rake db:abort_if_pending_migrations
• Added: rake db:rollback
• Added: rake db:version
• Added: rake mack:ring_server:start
• Added: rake mack:ring_server:stop
• Added: rake mack:ring_server:restart
• Added: rake mack:ring_server:services:list
• gem: application_configuration 1.2.2
• gem: daemons 1.0.10

Now that I’m back on track with DataMapper, I’ve got migration support for both it and ActiveRecord just about done. In addition to the actual rake task, db:migrate (btw), I had to set up a good way to test rake tasks, something I’ll share at a later date, but needless to say it’s included with Mack. I also had to deal with the pain in the ass-ness of dealing with two VERY different ORMs, in the same test system! Let me tell you, that sucked!

Good news is that things seem to be working, at least going in the ‘up’ direction anyway. I still need to write the ‘down’ direction revert stuff. Hopefully, that shouldn’t take too long now that I have a good way of testing the task and the migration stuff.

Unfortunately, I feel as though as soon as I release this stuff, which should be by the end of this weekend, DataMapper 0.9.0 will be out, and I’ll have to re-write most of the DataMapper stuff because the API is changing so radically. I guess I’ll just have to deal with that when the time comes.

In the meantime I’ll let y’all know when migrations are done and out there in the wild.

I was really hoping to get the rewrite of distributed routes using Rinda, as well as migration support for both ActiveRecord and DataMapper out either today, or by the end of the week. As it turns out, because of the Class bug in DataMapper 0.3.0 it doesn’t look like that’s going to happen till early next week. Sorry about that folks. I’ve lost a lot of time on the DataMapper thing, but I’ve got a work around, locally anyway, that is allowing me to keep developing. As soon as I get it all done, I’ll be very happy to release it all. Stay tuned.

So about 2 minutes after my post earlier about DataMapper a video was posted by one of the developers:

As you may, or may not know, DataMapper is the new ORM framework on the scene these days in the Ruby world. It’s getting a lot of hype for being clean, fast, simple, and feature rich. Oh, and it’s not ActiveRecord. I think that seems to be the real thing that is driving people to DataMapper, the fact that it’s not ActiveRecord.

I will say DataMapper is clean, simple, and feature rich. In 0.3.0 they’ve added migrations, which is great. Btw, a little off topic, but I’m working on migration support for both ActiveRecord and DataMapper in Mack as we speak. It should, hopefully, be out sometime this week. What I won’t give DataMapper is that it’s fast. In my tests, and I’ll provide some number below, DataMapper only seems to win on inserts, after that ActiveRecord beats it hands down. In all fairness to DataMapper I’m starting to think that the problems are not at the DataMapper layer, but at the underlying Data Objects layer that DataMapper uses. As you’ll see from my tests DataMapper seems very heavily optimized towards MySQL over PostgreSQL. This, to me, leans towards a difference in the underlying adapters.

Another problem I have with DataMapper is that I have to set the ‘properties’ of the model inside the model itself. It’s an old school approach, and it does have the benefit of being self documenting, but it also has the drawbacks of constant maintenance and clutter at the top of your model. Not to mention potential conflicts when running through migrations, etc…

I’m also having one other little problem these days. This has only been a problem since I’ve gone DataMapper 0.3.0. At the end of some of rake tasks, if I have DataMapper required, I get this:

/usr/local/lib/ruby/1.8/test/unit/collector/objectspace.rb:25:in `collect': undefined method `suite' for Gem::VerificationError:Class (NoMethodError)
from /usr/local/lib/ruby/1.8/test/unit/collector/objectspace.rb:23:in `each_object'
from /usr/local/lib/ruby/1.8/test/unit/collector/objectspace.rb:23:in `collect'
from /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:58
from /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:213:in `[]'
from /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:213:in `run'
from /usr/local/lib/ruby/1.8/test/unit/autorunner.rb:12:in `run'
from /usr/local/lib/ruby/1.8/test/unit.rb:278

The rake task completed successfully, but I get this fairly random error message. If anyone out there is also getting this message, please let me know what it is. I’m open for ideas on this one.

Despite these issues I have with DataMapper, I’m going to keep striving to provide support for both it and ActiveRecord in Mack. I think it’s important to give people a choice and not force them to use the one I think is either easier to code for, or better. Both of which I’m not saying about ActiveRecord, but in technologies in general.

Anyway, enough of my blather, here are the test results I was speaking about:

Running time 1.693881 seconds. [MESSAGE]: DM: postgresql: Inserts
Running time 2.799189 seconds. [MESSAGE]: AR: postgresql: Inserts

Running time 1.368185 seconds. [MESSAGE]: DM: postgresql: Individual Reads
Running time 0.734143 seconds. [MESSAGE]: AR: postgresql: Individual Reads

Running time 0.917551 seconds. [MESSAGE]: DM: postgresql: Bulk Reads
Running time 0.121198 seconds. [MESSAGE]: AR: postgresql: Bulk Reads

Running time 2.309244 seconds. [MESSAGE]: DM: postgresql: Updates
Running time 2.079578 seconds. [MESSAGE]: AR: postgresql: Updates

Running time 1.802914 seconds. [MESSAGE]: DM: postgresql: Deletes
Running time 1.708714 seconds. [MESSAGE]: AR: postgresql: Deletes

Running time 0.433761 seconds. [MESSAGE]: DM: mysql: Inserts
Running time 2.621093 seconds. [MESSAGE]: AR: mysql: Inserts

Running time 1.073741 seconds. [MESSAGE]: DM: mysql: Individual Reads
Running time 0.207305 seconds. [MESSAGE]: AR: mysql: Individual Reads

Running time 0.827842 seconds. [MESSAGE]: DM: mysql: Bulk Reads
Running time 0.073593 seconds. [MESSAGE]: AR: mysql: Bulk Reads

Running time 1.204845 seconds. [MESSAGE]: DM: mysql: Updates
Running time 1.738602 seconds. [MESSAGE]: AR: mysql: Updates

Running time 1.010774 seconds. [MESSAGE]: DM: mysql: Deletes
Running time 1.251691 seconds. [MESSAGE]: AR: mysql: Deletes