Dave Cross has plenty of good points in here:
http://dave.org.uk/talks/lpm/2006/orm
Great slides!
Ovid on 2006-03-24T00:06:54
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.
Db may be a good source but...
lilstevey on 2006-03-27T13:12:12
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.
ORM
sigzero on 2006-03-24T02:08:57
So is there a "good" ORM module for Perl? I see Rose::DB and the ones mentioned in the talk.
What's wrong with ORM
davorg on 2006-03-24T11:10:45
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.
Re:What's wrong with ORM
sigzero on 2006-03-24T13:36:21
Dave::ORM? : )
I am joking!
I enjoyed the presentation as well.
Re:What's wrong with ORM
petdance on 2006-03-24T14:27:03
I only put Class::DBI in the title because I figured that it was more recognizable to people than ORM.
Re:What's wrong with ORM
perrin on 2006-03-27T16:47:26
You really need to look at Rose::DB::Object. It can do this for you, either from actual database relationships or from conventions (like ActiveRecord does), and if you don't like the way it does it, there's an API for changing it.
I disagree
Alias on 2006-03-25T13:24:15
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 database the application doesn't know of care about. As long as the application can be sure they aren't needed (for example, all the extra fields are nullable, or the application won't have to write to the table.
This means that the application is properly compatible with the database, and it is TESTABLE, and you won't but bugs cropping up because some DBA added a column called "store" what clashes with a non-data method you are using in your class.
