O/R mapping [was Re: [Bioperl-l] pipeline]

[Aaron J Mackey]

On Tue, 12 Mar 2002, Chris Mungall wrote:

> But on second inspection, it seems that you actually write your perl class
> packages as normal, then write a seperate specification of your object
> model, to tell Tangram what to map.
[...]
> What would be nice would be to dispense with the class/package files
> altogether and have the entire model specified by the Tangram definition,
> with all the behaviour methods going in seperate utility classes - this is
> more similar to the ontology stuff I was on about.

Yes, you should also look at Class::Tangram (and my
not-yet-released-but-soon) Class::Tangram::Generator (I'll send docs if
anyone's actually interested).  Basically, you don't need to write any
package code, just the Tangram schema, and Class::Tangram::Generator
dynamically creates all your classes for you; you can give your classes
additional methods if you want, but your point about only adding method to
utility classes is a good one.

> Furthermore, if you want any kind of querying facility, you have to go
> direct to the sql which involves knowing how it all maps which defeats
> half the point.

Well, no, Tangram abstracts away the querying as well; however, if you
needed to something fairly peculiar (I'm not sure what that might be), you
might have to drop to SQL, as you say.  To be honest, I've never (yet) had
to do that; Tangram's remote querying facilities have always been adequate
(so far ...).  And it seems that if I ran into an occasion where I did
have to use SQL, it would be more worth my time to extend Tangram a little
to be able to handle the abstraction.

Thanks for your opinions, I'm keen on hearing more.

-Aaron, a believer in OO-Relational mappings making life easier, sometimes.

-- 
 Aaron J Mackey
 Pearson Laboratory
 University of Virginia
 (434) 924-2821
 amackey@virginia.edu