The other reason why I made the decision was time. It’s very time consuming to constantly maintain two different, and with 0.9.0 extremely different, ORMs. There are plenty of features that I could’ve done faster, had I only been supporting the one ORM.

Now I know I might come under fire from some people for this, but it’s a decision that I think is best for the framework. If some enterprising developer out there wants to build a plugin, or a gem, that adds ActiveRecord support, then I’m all for it! Please do!

The question you’re probably asking yourself now, is when will this be happening. It’ll be happening in the next release of Mack, probably the end of this week or the beginning of next week.

Again, I’m sorry for those of you were hoping to use ActiveRecord with Mack. Check out DataMapper, I’m sure you’ll be happy with it.

Comments?

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 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

 

 

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.

When you create your mack app you can do the following which will add ORM support to your generated app:

$ mack my_cool_mack_app -o activerecord

If you already have a mack app you can very easily add ORM support by adding the following configuration parameter to the default.yml file:

mack::orm: activerecord

And also add a database.yml file to your config directory that looks like this:

development:
  adapter: mysql
  database: my_cool_mack_app_development
  host: localhost
  username: root
  password:

test:
  adapter: mysql
  database: my_cool_mack_app_test
  host: localhost
  username: root
  password:

production:
  adapter: mysql
  database: my_cool_mack_app_production
  host: localhost
  username: root
  password: