Saying Goodbye to ActiveRecord

15 views
Skip to first unread message

Mark Bates

unread,
May 1, 2008, 5:06:11 PM5/1/08
to mack-fr...@googlegroups.com

I’ve been wrestling with this for a while now, and I’ve finally made my peace with it. I’ve decided to remove native support for ActiveRecord from Mack. From now on it’ll be DataMapper by default, out of the box. This was not an easy decision to make. Essentially it boils down to one of the key tenants of Mack, use the best of breed technologies to build a best of breed framework. I truly feel that DataMapper, especially when it hits the 0.9.0 release, is the best ORM, and persistence, system out there. I also feel that it is a natural fit for the Mack framework.

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?

-------------------------------------------------------------------------------------------------
Mark Bates






Antonio Cangiano

unread,
May 1, 2008, 5:19:53 PM5/1/08
to mack-fr...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Bates wrote:
> 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?

Do you want your framework to be the most popular one or the best one
out there?

If you want it to be the best it can possibly be, then you made the
right choice.

Sincerely,
Antonio

PS: I say this despite the fact that ActiveRecord has IBM support for
DB2 and DataMapper currently doesn't.
- --
http://antoniocangiano.com - Zen and the Art of Programming
http://stacktrace.it | http://math-blog.com
http://twitter.com/acangiano | http://flickr.com/acangiano
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgaM/kACgkQqCqsu0qUj9TpggCfTEnIVo3mgsJdABpXeguq0GKh
TG8An1lQo7Q5uno8XOI6chgWOP6Yoagp
=Mmwv
-----END PGP SIGNATURE-----

Mark Bates

unread,
May 1, 2008, 7:19:32 PM5/1/08
to mack-fr...@googlegroups.com
Great question Antonio and the answer is I'd rather be better and
faster then more popular. Popular is for high school.

As for unsupported adapters, give DataMapper time and it'll get there.
With the big rewrite they're doing it'll be easier for those adapters
to be built, and I think people will build them.

I know I've made the right choice. I feel good about it.

--------
Mark Bates
ma...@markbates.com
617.512.7534
http://www.thebluewires.com

On May 1, 2008, at 5:19 PM, Antonio Cangiano <acan...@gmail.com>
wrote:

k...@kuwata-lab.com

unread,
May 1, 2008, 9:24:02 PM5/1/08
to mack-fr...@googlegroups.com
It is interesting. I'll respect your decision.
Could you explaing briefly about advantages/disadvantages of DataMapper
compared with ActiveRecord?

--
makoto kuwata

Mark Bates

unread,
May 1, 2008, 9:33:47 PM5/1/08
to mack-fr...@googlegroups.com
Thanks for the reply Makoto.

First off, there's speed. DataMapper is ALOT faster than ActiveRecord.
That's a HUGE part of the basis of Mack, speed. Then there's the code
and the framework itself. I feel as though DataMapper is being written
by database guys, and not developers who happen to know databases,
which is how I feel ActiveRecord is. There's things like support for
compound primary keys, the identity map, it's 'syntactic sugar' in
respect to things like building queries, to name a few. The upcoming
0.9.0 release of DataMapper is re-focusing DataMapper to be more than
just an ORM, but to be a 'persistence' framework. The database just
happens to be a way to persist something, but it's not the only way.
Other languages and platforms have moved on to the idea of
persistence, but ActiveRecord/Rails hasn't.

I have other issues with some of things that ActiveRecord does,
including a dangerous little method that bit me hard once, a method
called, disable_referential_integrity. The fact that they even had
that method, and that it was turned on by default, did not make me a
happy camper. There's things like that that have pushed me away from
ActiveRecord. There are things that it has done well, that I'll miss,
for example the has_many :through, which DataMapper doesn't do,
currently.

If you haven't seen it, this video is a great intro to what DataMapper
0.9.0 will be: http://mtnwestrubyconf2008.confreaks.com/04katz.html

I am slightly concerned that I might be alienating people from Mack,
because I won't have native ActiveRecord support baked in, but I would
like to think that, in the end, it's the best thing for the framework
to pick the best technologies out there and to optimize for them.

-------------------------------------------------------------------------------------------------
Mark Bates
ma...@mackframework.com
http://www.mackframework.com
http://api.mackframework.com/
http://github.com/markbates/mack

k...@kuwata-lab.com

unread,
May 2, 2008, 1:04:19 AM5/2/08
to mack-fr...@googlegroups.com
Thank you, Mark.
In my opinion, Slow speed of Rails is due to Rails itself
and not to Ruby.
I hope Mack will be the fastest framework in Ruby.

--
regards,

Sam Smoot

unread,
May 2, 2008, 5:19:29 AM5/2/08
to Mack Framework
Thanks for the kind words!

DM 0.9 is tantalizingly close (I suppose I might just release gems on
github for it). DO 0.9 is basically done; just need to ensure all the
drivers cover all the basic primitives and add idle-connection
flushing to the connection-pools.

We probably have around 3X as many specs as previous versions, and the
new DO is easily an order-of-magnitude faster than before.

There's work yet to be done (has_many:through), and a few niceties to
get to here and there (auto-include dm-validations when required), but
it's close enough that I started switching my work projects over from
DM 0.3.2 to DM 0.9.0 yesterday. Which explains all the commits if
you've been following the git commit list. :-D

We also have a new CI server: http://ci.datamapper.org

We'll do our best not to let you down. And if you'd like commit-access
or need some support, feel free to IM me (google-talk) or shoot me an
email. Though the guys on IRC (#datamapper) are extremely helpful as
well considering we've all got day-jobs. ;-)

Mark Bates

unread,
May 2, 2008, 8:57:33 AM5/2/08
to mack-fr...@googlegroups.com
Hey Sam, thanks for the email. I've been following the activity on
GitHub, and it's nice to know that 0.9.0 is getting close. I'll branch
Mack and start converting it over to the 0.9.0 so it's ready when you
guys are. It's a shame that neither habtm and has_many :through aren't
working though. That means I can't convert a couple of my projects
over to it yet, but I can't wait.

I would love commit-access, if you're offering. I would like to think
I have a few things to offer to the project, God knows over the years
I've really wanted to patch AR. Also, if you'd like to commit-access
to Mack, just let me know.

Keep up the good work.

-------------------------------------------------------------------------------------------------
Mark Bates
ma...@mackframework.com
http://www.mackframework.com
http://api.mackframework.com/
http://github.com/markbates/mack

Mark Bates

unread,
May 4, 2008, 11:30:09 AM5/4/08
to mack-fr...@googlegroups.com

k...@kuwata-lab.com

unread,
May 4, 2008, 8:33:14 PM5/4/08
to mack-fr...@googlegroups.com
Mark,
I think your decision is very practical.
It may be required 'Rack on ORM'.

--
regards,
makoto kuwata

Reply all
Reply to author
Forward
0 new messages