tags:

views:

1217

answers:

10

This recent question on doing ORM in Perl proved somewhat timely, as I was just looking at Perl ORMs yesterday. Unfortunately, I was not particularly satisfied with what I found:

They all appear (at least in their documentation) to focus primarily on the relational side of the object-relational divide. "Use our ORM to provide an OO(ish) interface to your relational database."

But I'm not a database programmer who wants to invoke methods instead of writing SQL. I'm an OO programmer with a need to persist objects.

Are there any good Perl ORMs that openly support objects that have more complex behaviours than just CRUD operations? Things like inheritance and properties which aren't just a wrapper around a database field?

I'm sure that this is possible with Class::DBI, DBIx::Class, Rose::DB::Object, and all the smaller players, but, in every case but one, the docs that I've been able to find don't even mention these topics, never mind providing an example of how to do them within the context of that framework. (The one exception is PerlORM, which, aside from appearing to be incomplete and unmaintained, claims to be "only" 20-30% slower than Class::DBI (the slowest of the Big Three).)

Update (July 13, 2009): To clarify in response to Chas. Owens' response, my complaint isn't with the involvement of an RDBMS, but rather that the major ORMs (in most languages, really, not just in Perl) seem to focus on mapping the relational model into the object space. I want to map the object model into the relational space. Which is, yes, a form of object persistence, but it is also a form of object-relational mapping.

It is also substantially more difficult than the normal way of doing things, as the relational model is more limited than the object model, at least for the kinds of things I normally want to do, but it is possible. I know this because a coworker and I built such an ORM many years ago (long before I first encountered the term "ORM" - we called it an "object-relational persistence layer") in Borland Delphi and I have built my own half-assed implementation of that style of "object-to-relational mapper" (as opposed to the normal "object-from-relational" version) in Perl, but I don't really relish the thought of pushing it to become fully-functional and solid enough to use in production applications. Thus my interest in finding out whether someone else has already done it, so that I can use their very-complex wheel rather than rebuilding it myself.

+8  A: 

This has been a dilemma of ORM tools for many years. There's no way to avoid sacrificing part of your paradigm. Either you sacrifice some features of object-oriented architecture, or else you sacrifice some features of relational databases.

Even Bjarne Stroustrup and Bell Labs concluded that you should not try to marry OO and RDBMS.

If you have objects that you want to persist into a database, then serialize them and store them in BLOBs. Of course this limits your ability to query them with SQL, but you can retrieve them and unserialize them as objects. But you're using the database as a kind of persistent cache, you're not using it as an RDBMS.

If you want to retain the use of the RDBMS paradigm, using queries to match result sets, then you must instead compromise some aspects of OO data. You can still have an OO interface to connect to, query, and retrieve results from the database, and you can map very simple objects to rows in a table, but you can't do that with more complex objects.

Bill Karwin
I've never had any trouble mapping my objects to tables in a database. Where is the difficulty?
postfuturist
+12  A: 

For OO persistence then have a look at something like Pixie, Tangram (both of these are covered in "Advanced Perl Programming" book by Simon Cozens), or the new KiokuDB.

Depending on what your requirements are you may find Moose and using something like MooseX::Storage more appropriate.

/I3az/

draegtun
+15  A: 

Take a look at KiokuDB. It provides storage of Moose based objects and provides a way to query them. Haven't tried it myself, but I came across it this morning and looked like an interesting project.

mpeters
Well found! Looks very nice so gets a +1 from me because its something I'll keep an eye on. While going thru KiokuDB link it references another OO module that escaped my original answer.... OOPS http://search.cpan.org/dist/OOPS/
draegtun
A: 

Do have you to use Perl? If this is something that is very important to you, maybe you want to use something like Gemstone, which you can use with Java, Smalltalk, and I think their own (faster) Ruby implementation.

brian d foy
It's not absolutely mandatory, no, but Perl is my language of choice and if I took all of my OO projects with persistent data elsewhere, there wouldn't be much left over to use Perl for.
Dave Sherohman
Gemstone is not even an RDBMS, its some smalltalk-y 'Object Database', you know, like CODASYL or MUMPS, such things get pretty tied to specific applications instead of being general databases.
MkV
+1  A: 

Rose:DB may be useful to you. We've used it a number of times; performs reasonably well, and is more object-flavored. It is possible to break out into SQL if you need to for efficiency.

Joe McMahon
A: 

Would alzabo or DBIx::SearchBuilder do what you want?

Joe Casadonte
"Are there any good Perl ORMs that openly support objects that have more complex behaviours than just CRUD operations? Things like inheritance and properties which aren't just a wrapper around a database field?" I see nothing in either link to suggest that alzabo or SearchBuilder cover this.
Dave Sherohman
+1  A: 

UR might be what you're looking for. It has ORM features, but can be used without a database as yet another class framework.

Mark Johnson
Interesting... I hadn't heard of UR before and it looks like it warrants a closer look. Thanks!
Dave Sherohman
It's an internal project that's just been unleashed upon the world recently. The documentation is a bit thin in places. If you have any questions, ask away, and I'll try and answer or drag one of the developers over here to do so.
Mark Johnson
+2  A: 

Have a look KiokuDB and it is a Moose based object oriented persistence frontend for a number of storage backends.

KiokuDB focuses on predictability and transparency, providing quick, easy and noninvasive persistence while minimising the undesired surprises caused by naive serialization approaches.

joe
See http://stackoverflow.com/questions/281803/is-there-an-object-centric-perl-orm/281980#281980 and http://stackoverflow.com/questions/281803/is-there-an-object-centric-perl-orm/282022#282022
Sinan Ünür
its link to same page ..
joe
They are links to the answers that already suggest `KiokuDB`.
Brad Gilbert
A: 

ORM stands for Object Relational Mapping. Any ORM you find will deal with a relational database. What you need to be searching for is Object Persistence.

Chas. Owens
A: 

like many others said what you are referring to is Object Persistence. I like to call it Object serialization. the fact that you store your serialization in a relation model has nothing to do with ORM's

everybody is hitting this web page looking for the wrong stuff