[Bioperl-l] SeqFeature containment hierarchies

[Hilmar Lapp]

On Thursday, July 17, 2003, at 04:27  PM, Chris Mungall wrote:

>
> Hilmar - does this affect the biosql code?

Not negatively in the sense that you'd duplicate the feature, iff you 
don't duplicate the feature in the object tree either. (Obviously I 
haven't been able to test this yet. And see below for why this may even 
be wishful thinking of mine, especially given the fact that seqfeature 
relationships is not even supported through bioperl-db yet.)

>  Would this lead to multiple
> updates of the same exon when storing a gene model?
>
>

Possibly. The impact of this may not be that dramatic though.

I've just a few days ago introduced a 'dirty' flag that avoids an 
update if a persistent object is marked as non-dirty. In a freshly 
constructed object or object tree everything would be flagged dirty 
though.

The code that turns objects into persistent objects goes in low-level 
and replaces every object in a hash or array ref with its persistent 
counterpart if there is one. I suppose that if that feature object is 
stored twice in the tree of hash/array-refs then it would result in two 
distinct persistent objects being wrapped around it.

The UK-constraint on seqfeature in biosql is the combination of 
(primary_tag,source_tag,bioentry,rank). Bioentry is the foreign key to 
the sequence (entry) on which the feature sits. Rank is an artificial 
attribute that exists only on the persistent object wrapper, apart from 
the schema. Hence, setting it on one wrapper would not affect the 
other, even if both wrappers pointed to the same underlying feature 
object.

Supposedly the insert/update logic would be such that first all 
participating features would be inserted or updated. Then the 
relationships would be serialized, without triggering another update or 
insert on the feature objects.

How did you guys implement this for chado?

I'd be keen to have a full test case on which we could define the 
desired behaviour and then implement it. So far I'd have had to 
construct something artificial. This has changed now with your genbank 
unflattener.

	-hilmar
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------