[Bioperl-l] pipeline

[Ewan Birney]

On Tue, 12 Mar 2002, Imre Vastrik wrote:

> Elia Stupka wrote:
> > 
> > > I know I won't make many friends with this suggestion but what about
> > > revamping the whole "schema" (and I don't mean the table.sql file here)
> > > so that all the object<->relational mapping would be done automagically?
> > 
> > I like the idea a lot actually, and I was kind of aiming in that
> > direction. However, I am not sure if that solves the problem of being able
> > to take *a part* of a schema and moving it in another database, thus
> > changing in practice the table the foreign key is referring to (seq_id in
> > the alignment example)
> 
> I don't understand your concern here but that's prolly because I don't
> know the very issue. You would nevertheless have to make your code
> "aware" of the fact that whatever the object/attribute the foreign key
> is referring to also now comes from "your db" as opposed to the other
> db/schema/module you snatched it from.

This is *definitely* Arne's call inside Ensembl. Arne is sick today.
(bizarrely three of us are sick/at home/whatever today it seems - Manu,
Arne and myself)


I think Arne has toyed around with the idea of having the schema defined
inside the adaptor and emitted somehow - I think all that is holding him
back is time --- we need to get the new objects working well).


Re: auto-generated object<->relational systems. From someone who has only
seen this from afar (but a number of times - OPM, other things...)

  (a) There is no standard. People always want to write their own system
to have control over some aspects of it

  (b) It seems to generate hard-to-find bugs. Of course, this may be
because the system is so good the standard "easy to find" bugs are
eliminated. Because the system gets complex, in general it ends up that
these bugs bottleneck on one person who understands the O<->R mapping
system

  (c) It seems to encourage large numbers of objects which actually
prevent understanding the system well.


  (d) it becomes hard or virtually impossible to view the data as pure
"data" as we do in things like Lite. I used to be against a pure data view
of the world, but experience over the last couple of years, and watching
what people can do with the data view (eg, Arek) has changed my mind.



Elia - your/Jerm's proposal looks on track. I'll read it more carefully
and comment.


> 
> Rgds.,
> 
> i
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------