From: Sam Smoot <ssmoot@...>
Date: 2008-02-20T10:54:57+09:00
Subject: Re: Comparing Active Record VS Datamapper...?

On Feb 12, 11:13 am, "S. Potter" <mbbx6...@tautology.net> wrote:
> Actually for Ruby programmers as opposed to people that only know APIs
> in Ruby, extending the APIs for specific use-cases is very painless.

Ouch Susan. :-)

One of the reasons I've started DataMapper was because working with AR
to make multi-lingual extensions, and handling UTF-8 to UTF-16LE
conversion transparently (for MSSQL support) in 0.9~1.2 was far far
from trivial.

Not that smart people didn't eventually figure out how to do these
things, but to say it's painless makes me suspect you're either just a
whole lot smarter than me, very intimate with the internal workings of
AR, or you're talking about more recent efforts as AR has matured.

DM has much less magic. It's much easier to tweak (IMO). But then
again, I am intimately familiar with it, so it's hard to keep an
objective eye in this regard... so maybe I should say "I think/hope
it's much easier to tweak".

Anyways, overall I would say your evaluation of DM is generally fair,
if not too accurate architecture wise. DM right now is actually a
pretty classical Data Mapper according to the designs of the PoEAA.
Some of the names are a bit off, but DM doesn't deviate significantly
more or less than many of the other O/RMs implementing the pattern out
there. The extensions made to the models are there for convenience of
the user for the most part. The exceptions are the #key method, and
the #database_context method. Every DataMapper is going to have a
parallel for the latter (#database_context), but I concede the former
(#key) is not as common. I was just being lazy I suppose. ;-)

On the other hand, the architecture you describe for DM is almost spot-
on for where we'd like to take it in the future. I've accepted that
some of the unique challenges in working with Ruby are leading me to
design decisions I might not otherwise have made... Basically, I'm
trying to explore ways to make DM "flatter"/faster, without
sacrificing design too much. One of the ways we plan to accomplish
that is by making the models themselves the center of the mapping
"star" for DM. It's not the sort of PORO purity I imagined before, but
it's a reasonable compromise I think, and there's really no downside
if I'm pragmatic about it.

I've gotta take exception with the "slam dunk"/simpler comment
regarding AR. You've got to define the attributes somehow. In DM you
do that in the model, in AR you write a migration or do it in your
database. Either way you've got the same tasks. At the end I think
DM's simplified finders win the day for me though. It's just painful
to go back to Thing.find(:first, :conditions => ["name = ?",
'something']) when I could be writing Thing.first(:name =>
'something').

But I'm biased. :-D

I do think AR wins big in the setup department just because it
provides pure-ruby drivers for many databases. So you can be running
ASAP. We hope to improve on our currently poor platform support in the
next few weeks with the release of DataObjects 0.9.0. (We're about
half-way there right now.)