> 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. ======================================================================= _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
