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

[Chris Mungall]

On Tue, 12 Mar 2002, Aaron J Mackey wrote:

> 
> On Tue, 12 Mar 2002, Chris Mungall wrote:
> 
> > >   (a) There is no standard. People always want to write their own system
> > > to have control over some aspects of it
> >
> > yup; you'd think that if this approach was sound there would be some
> > decent tool to do this by now, rather than thousands of incompatible
> > pieces of crap.
> 
> What say you about Tangram in this regard?

Hmm, I last looked at Tangram when it was in the very early stages. You're
email has sent me scurrying off to read about it...
 
> > Also: (e) for queries more complex than can be dealt with by canned
> > templates, you end up either bypassing the O/R layer, or writing a complex
> > non-standard object query language, or forcing the api user to slurp
> > everything into memory and do the query with imperative code.
> 
> Again, how do you compare Tangram to this statement?  I've found Tangram
> to be very useful, but perhaps I haven't run into the barriers you have ...
> 
> Just curious, thanks for any feedback.

Just had a quick scan of tangram-persistence.org

At first I really liked the look of it - at first it seems as if you don't
have to bother creating any actual class packages, everything being
defined by the Tangram model.

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. So already your model
conceptualisation is starting to spread out. You also get into problems
such as, are you mapping attributes or accessor methods to attributes? I
could be wrong, but I think it would be impossible to take something like
the bioperl object model and map it to a de novo schema using Tangram.

I think that as these things go, Tangram is quite nice, but it suffers
from the same problems all the others.

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.

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.

> -Aaron
>