[Biojava-l] FeatureHolder.containsFeature()

[Schreiber, Mark]

> Could I propose that with regard to DB-backed persistent 
> objects, Feature objects store the unique id of the feature 
> within them and containsFeature only returns true if the 
> feature of that unique ID is a child of another feature whose 
> feature unique id places it somewhere on the direct ancestral 
> lineage en route to the sequence object (yuck, what an awful 
> sentence!)?
> 
> This will survive any number of instances of that feature 
> object and its parent sequences being checked out of the 
> SequenceDB and this survivability may become important when 
> we consider what to do with
> removeFeature() [ie. here, with multiple instances checked 
> out of a DB-backed Sequence DB, should removeFeature() remove 
> the feature in all checked out copies?  This bites with a 
> vengeance if there's more than one client machine connected 
> to the same DB.  How do different machines know if the 
> features on a sequence you have checked out have changed?  
> Should we even contemplate such an eventuality?]
> 

I kind of like the idea of unique IDs esp if they can be calculated to
reflect heirachies that can be rebuilt after your beautifully nested
feature heirachy has sufferred the horrors of being reduced to a flat
file (in ASCII no less!!). 

For DB backed sequence DB objects the idea of multiple checkouts and
resolution of changes should be handled (usually by locking) by the DB,
however ....

What if, when a user checks out a sequence the sequence is created by
the DB servers JVM and an interface to it is exported to the user via
RMI. (Yah for the Serialization upgrades to biojava). Now when multiple
users start messing with a sequence by calling the removeFeature()
(which will be marked as synchronized of course!) they are actually
dealing with the same sequence rather than copies of the sequence which
must be merged/ rejected when they are commited back. After the sequence
has no more users it can be commited back to the DB (flat file or
relational).

Heck that's the best use of RMI I've ever come up with!

Mark
=======================================================================
Attention: The information contained in this message and/or attachments
from AgResearch Limited is intended only for the persons or entities
to which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipients is prohibited by AgResearch
Limited. If you have received this message in error, please notify the
sender immediately.
=======================================================================