Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

petdance (2468)

petdance
  andy@petdance.com
http://www.perlbuzz.com/
AOL IM: petdance (Add Buddy, Send Message)
Yahoo! ID: petdance (Add User, Send Message)
Jabber: petdance@gmail.com

I'm Andy Lester, and I like to test stuff. I also write for the Perl Journal, and do tech edits on books. Sometimes I write code, too.

Journal of petdance (2468)

Thursday March 23, 2006
06:27 PM

What's wrong with Class::DBI and other ORM packages

[ #29086 ]
Dave Cross has plenty of good points in here: http://dave.org.uk/talks/lpm/2006/orm/
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Great set of slides. David (theory) and I were dealing with something similar except we create the db metadata from our classes rather than the other way around.

    • I found that whilst the database can be a very good source for a lot of metadata and relationship stuff, it can be advantageous to extract this information, into say XML, which can then have further hints applied to it, and the output of this can be used as the source for objects, database code and such.

      Just because some of your data is in a database at the moment doesn't mean it always will be, and your objects may outlive the implementation of a store.
  • So is there a "good" ORM module for Perl? I see Rose::DB and the ones mentioned in the talk.
  • I should point out that the only reason I concentrated on Class::DBI was because it's the ORM system that I know best. All ORM systems that I've looked at suffer from at least some of the same shortcomings.

    The idea first came to me when I first saw the amount of repetition needed to set up classes in ActiveRecord. And, of course, they get round the DRY issues by not defining anything clever in the database. Which is just wrong.
  • While it sounds like an interesting idea, I disagree quite strongly.

    What he's suggesting is that we automagically change the code and API based on the structure of the database.

    This is just ASKING for weird bugs to crop up.

    You really DO need to have BOTH halves of the application (code and database) independant for anything but the most trivial application.

    What IS necesary though, is that your application knows whether or not it is compatible with the database.

    For example, there could be extra fields in the