[Biojava-l] FeatureHolder.containsFeature()

[Keith James]

>>>>> "Mark" == Schreiber, Mark <mark.schreiber@agresearch.co.nz> writes:

    >> 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!)?

As all the bio projects support nested features and therefore face the
same issue I think it would make sense to have a common,
platform-independent way of doing this. I won't x-post this yet, but
maybe bioperl/pythoners are reading anyway... Maybe there is already a
plan?

[...]

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

It's a horrible thought, isn't it? You really need to do this? We
round-trip to flat files, but it's something I'm hoping we get rid of
asap.

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

I agree.

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

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

That's pretty neat. However, this locks out any concurrent non-Java
access doesn't it? I don't know whether the bioSQL schema was
envisaged to support, say BioPerl and BioJava clients accessing the
same resource simultaneously, but it seems to me that should remain
possible.

Keith

-- 

-= Keith James - kdj@sanger.ac.uk - http://www.sanger.ac.uk/Users/kdj =-
Pathogen Sequencing Unit, Wellcome Trust Sanger Institute, Cambridge, UK