Re: Hibernate and ActiveRecord (Ruby-on-Rails) comparison

[prev] [thread] [next] [Date index for 2005/04/04]

On Mon, Apr 04, 2005 at 06:24:11PM -0400, Perrin Harkins wrote:
> I thought this article was pretty good, and might help others understand
> some key differences between what Class::DBI and what Hibernate does.
> Ruby's ActiveRecord, which is what Ruby on Rails uses, is very similar
> to Class::DBI (almost identical I would say).
> http://theserverside.com/articles/article.tss?l=RailsHibernate

This is certainly very interesting, and a useful comparison of the two.
I think the author's arguments are flawed though.

The main arguments seem to be:

1) It's better to declare your columns in code, rather than letting the
code ascertain this from the database

In Class::DBI we can do either (albeit with plugins), and I presume
ActiveRecord can too. In general I dislike duplication, so withere
possible I prefer the approach of letting the code look the data
up. It's certainly more useful whilst you're in heavy development and
still changing your schema.

The author's argument is it's a pain to go across to your database and
look up what the columns are. I'd agree. So in most of my CDBI apps, I
keep the schema definition in the __DATA__ section of the class! That
gives me the best of both worlds. 

I certainly don't see this as a serious comment on either type of
approach!

2) ORMs should auto-save changes without having to manually save()

I've seen this argument quite a few times, and I've never quite bought
it. I suspect this is more true for people who want a way to work with
objects that persist without ever really thinking they're dealing with a
database. CDBI (and I presume AR) is more for people who "think" in
database terms, and want rid of much of the drudgery. Before I had CDBI
I'd still have to issue lots of UPDATE statements. CDBI just simplifies
that.

3) AR makes you write SQL for complex queries, whereas Hibernate has
its own Query Language

I think people know my views on this. SQL is good, not bad. It does
the job well. Trying to reinvent it is a folly. I actually think AR has
fallen into the trap of trying to reinvent too much of SQL internally
as well. But HQL looks appalling to me. 

4) AR's lazy loading is a Bad Thing.

This is based on the statement that "one of the best way to improve
performance is to limit the number of trips to the database.  Better 1
big query than a few small ones."

This gets trotted out a lot. But it's a massive oversimplification. I've
seen many cases where it's much better for performance to break a big
query into thousands of of small ones.

That said, one of the things I'd like to see in CDBI is a way to inflate
several classes simultaneously from an actual join. It shouldn't be too
hard to do - I've just never needed it yet enough to write the code
rather than just inlining some SQL.

5) Hibernate has better caching than AR

I don't really know either of these enough to compare them, and the
author doesn't really give any detail. The 'first level cache' he talks
about in Hibernate looks like the one we have in CDBI. The 'second level
cache' looks like what some people have talked about writing for CDBI,
but again, I've never needed this (whereas the environments in which
I've used CDBI mostly heavily have had multiple webservers running
against a single database, where this level of cache is usually a Very
Bad Thing).



Summary:

I think this article is a useful summary of some of the differences
between AR and Hibernate. I don't really know either of those well, but
this article makes me think that they fall on opposite sides of the
"store objects in a datbase" and "represent a database as objects"
divide. If this is true then the article certainly understates the huge
philosophical differences between those positions.

Based solely on some of his complaints about AR, I would guess that he
would have less (or at least significantly different) complaints about
CDBI. I suspect that a large part of this is due to the fact that Active
Record is still quite young. 

Rails has interested me for quite a while, but the bit I like least
about it is that all the components are part of the same suite and
developed together. Compared to something like Maypole, I much prefer
that the development of Maypole is focussed just on the "MVC framework"
part, relying on separately developed technologies like Class::DBI and
Template::Toolkit underneath. (The part of Rails I found weakest is
its TT equivalent).  But then Perl has CPAN, which nothing else comes
anywhere near yet...

Tony