[Catalyst] What value does an ORM add?

Adam Jacob adam at stalecoffee.org
Thu Jun 8 18:02:00 CEST 2006


On Jun 8, 2006, at 8:33 AM, Steve Atkins wrote:

> Not intending to start any sort of rancorous discussion, but I was
> wondering whether someone could illuminate me a little?

I'll give it a shot.

> I'm comfortable with SQL, and with DBI. I write basic SQL that runs
> just fine on all databases, or more complex SQL when I want to target
> a single database (ususally postgresql).
>
> What value does an ORM add for a user like me?

Well, if you are writing large-ish applications, the odds are you are  
already wrapping that SQL up in accessor methods most of the time.   
You know how it goes, you get some values back that need to update  
some part of the database, so you roll a little subroutine that takes  
some data structure and maps it to the database.

Or you just roll a routine that gets a list of things, and returns  
it.  Just so you don't have to type the same bit of SQL over and over  
again, or if the schema changes, you only have to worry about fixing  
it in that one spot.

> Some ORMs provide a single interface to the underlying datastore, so
> allow you to cache information in the ORM, as long as you're the only
> app accessing the underlying datastore.

So, ORMs provide a single interface to that underlying datastore.   
Different ORMs handle this totally diffferently.  In the case of  
DBIx::Class, it's about providing a mechanism where you can easily  
have the results of your queries turned in to useful perl objects for  
you without much effort.  Just like you do for yourself in raw DBI.

As for caching, that can happen in some ORMs; but it's rarely the  
reason to choose one.  You could get the same effect yourself, by  
hand, in a pretty easy and reliable fashion.

> Higher level modules (authentication, say) can target the ORM API and
> not need to worry about database-specific details (although they
> usually use such simple SQL that they could get the same independence
> by using DBI directly it's still a decent implementation choice).

The magic here is really in the schema abstraction.  You can easily  
point the higher level modules at a "table", and have it just do the  
right thing.  If there are relationships between that table and  
others, accessor methods get created.  It's good stuff.

> But that seems to be about it.

It's a lot. :)

> I know that I don't need to use an ORM with catalyst - I can use DBI
> perfectly well, or even a hybrid system where my code uses DBI and
> other modules use an ORM. But there's so much excitement about ORMs
> that I have to wonder whether I'm missing some big concept about
> them, and there's something they offer that makes development quicker
> even for someone fluent in SQL.

I have found a huge increase in my productivity since I started using  
some kind of an ORM for most of my perl database access.  I'm totally  
capable of writing raw DBI/DBD style applications.  But I always  
carted around, or re-invented, the "modeling" layer.  With  
DBIx::Class, I give up a little in raw speed, but I get back the  
ability to do (from Catalyst):

my $resultset = $c->model('DB::Monkeys')->search(
	{
		'hungry' => 1,
		'karma' => { '>', '250 },
	},
	{
		'order_by' => [ karma ],
		'prefetch' => [ zoo ],
	},
);

 From that, I will get back a list of all the hungry monkeys whose  
karma is high enough to warrant some extra bananas.  Since I know I'm  
going to drop those banana's off, I go ahead and pre-fetch the zoo  
they belong to as well (which is in another table.)  DBIx::Class  
knows how to do the join properly, and it returns to me an object  
that I can:

A) Use to efficiently walk through my query.
B) Read or Update the fields in a given row.
C) Refine the resultset based on another query. (So if I then wanted  
to get all the monkeys who are brown, I could just feed off the  
resultset I already have)
D) Chase the relationships I didn't prefetch through accessor methods.

I'm sure there are more.  What I paid for that convenience was speed,  
and I gained back a huge level of functionality, portability, and  
code clarity.

My $0.02.

Adam



More information about the Catalyst mailing list