Meta Bates

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.

http://wm.lighthouseapp.com/projects/4819-datamapper/tickets/185-including-comparable-in-class-class-breaks-test-unit-and-probably-more#ticket-185-8

In the gem at the bottom of lib/data_mapper/support/typed_set.rb there is the following code:

class Class
  include Comparable
  def <=>(other)
    name <=> other.name
  end
end

This causese Test::Runner to through up an error similar to this:

/usr/local/lib/ruby/1.8/test/unit/collector/objectspace.rb:25:in `collect': undefined method `suite' for Gem::LoadError: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
from /usr/local/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake/rake_test_loader.rb:5
rake aborted!

It also causes your tests to blow up and not run. Which, if you’re trying to do any development causes some real problems! If you comment out ‘include Comparable’ from Class things seem to work just fine. I say seem, because I haven’t done any real extensive testing with this. The other thing you can do is revert to 0.2.5, but that’s up to you. Either way, it’s not really optimal. Let’s hope they fix this soon.

I’ve been asked by people why I’m not using spec tests to test Mack. I’m currently using just plain old regular unit tests for my tests. It’s a good question, but not really a valid one, I think. Should it matter what type of tests I’m using as long as I’m testing? Tests are tests. The framework you use to do your tests is moot as long as the tests you write are good, solid tests.

I jumped on the spec test bandwagon about a year or so ago. I forced my whole team to start writing in nothing but spec tests. The team, is still not impressed. If I were to tell them we weren’t using spec tests anymore, they would be EXTREMELY happy with that.Spec tests are certainly prettier than ‘regular’ tests. I’ll give you that. They are more ‘human readable’. With that said I find assert_equal to be fairly easy to read.

So why do I use regular tests, and not spec tests? A couple of reasons. First, they’re there and built right in to Ruby, ready to go, no new gems or syntax to learn. They’re fast. They are faster than spec tests. I see it everyday at work. I can also, and this one is HUGE, run just a single test or a regex’d series of tests. I really love that last bit. I have yet to find a way to do that, easily, with spec tests.

Again, how people write tests doesn’t really matter so much to me, it’s just that they write them. Testing is too easy in Ruby, there’s just no reason for not writing them.

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