Meta Bates

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

 

 

Why did I fall in love with Rack and Thin? That’s easy. I love Thin because it lives up to it’s name. It’s thin. It’s incredibly fast, has great clustering support built in, and is the next generation of Ruby web servers. It kicks Mongrel’s ass and it takes names. I’m sure if you asked Zed Shaw he would have no problem with Thin replacing Mongrel.

Rack I love because of it’s simplicity, and it’s uniformity. It’s setting out to create a standard for which any Ruby web application can very easily be plugged into a web server. By abstracting that layer out it makes it easier for developers to focus on writing great apps, and not having to worry about how to deploy them.

Once I started to play around with Rack it didn’t take me more then a few minutes to have a very simple site up and running.

Within a few days I had the basics of a Rails like framework rocking, and within two weeks I had the core of Mack coded, and that’s where I am today.

Mack is a very fast, stable, and extensible framework. It’s designed to be lean and mean and not be all things to all people. It’s meant to get you started on the right path, but to let you have your own opinions. It’s designed to help you build portal applications simply and efficiently, and deploy with just as much ease.

Mack is ORM agnostic, although it does have some special hooks for ActiveRecord and DataMapper. It does not force you to use a certain type of system for doing web services, although it does promote a RESTful lifestyle. Configuration and setup is system, but there’s no reason for you to use it as is out of the box.

Mack encourages experimentation, and  it hopes that you customize it make it your own.

Go and scour through the API and then download the gem and start building your next generation application the way YOU want to, not the way someone else tells you you have to.