[Bioperl-l] Opening up deleting features from Seq objects again
Thu, 25 Oct 2001 22:33:16 +0100 (BST)
On Thu, 25 Oct 2001, David Block wrote:
> This is a natural outgrowth of SeqFeature::Gene::GeneStructure et al.
> Once you have structured data in memory, flush/add is not appropriate all
> of the time.
I don't like flush either ;)
> And what is the problem with having a working implementation of
> delete_feature? You don't have to use it...
I'd prefer it in its own file. I forsee... growth of this beyond delete
feature (delete annotation, edit, assign user...) If you want to keep it
in the Bioperl name space then that's ok, something like
> > There are other "update policy" systems for database access (Bioperl-db
> > follows a more cvs publish/update type model - ish)
> Of course, that's fine if that's what you want, but how do you dynamically
> decide what goes into the next update? Bio::Seq should be able to remove
> one of its features from memory - this may or may not affect the
> underlying persistent storage.
I really think we want to remove updateable implementations outside of
more read-only implementations - it is I think asking for Bio::Seq to
become a maintenance nightmare and trigger alot of GenQuire things to go
through Bio::Seq implemetentation.
> > Furthermore, I have a sneaky suspicision that the feature delete
> > requirements becomes a bit of a can of worms wrt to things like multiple
> > users.
> We have a lock system so that users must register locks on portions of the
> database. Bio::Seq _has_no_persistence_mechanism_, so no two users are
> ever looking at the same memory space. What's your problem?
You don't know that. Two things in a script could be holding onto a
reference to a Seq object assumming it stays constant through calls.
> > What I think you should go for is this sort of model
> > # interface that GenQuire needs for a sequence objects to be
> > # editable
> I already have all of this - I want to make this portable for the benefit
> of SeqCanvas, not for Genquire.
I don't see a big distinction between the two, but I do think having an
updateable sequence in the bioperl namespace is ok if you want to make the
> > Bio::GenQuire::UpdateableSeqI
> > # implementation of this in pure Perl, can inhereit from
> > # Bio::Seq if so wished to reduce coding
> > Bio::GenQuire::Seq
> > # implementation of this with DB backend
> > Bio::GenQuire::DB::DavidsNameSpace::Whatever
> > This mirrors what we have done in Ensembl, separating out the "Ensembl
> > specific" interfaces into Bio::EnsEMBL::* space, and therefore not
> > inflicting Ensembl's update model on everyone else (not that we have one).
> But that doesn't allow people to use Ensembl on any old Bio::Seq, which is
> what we want from Bio::Tk::SeqCanvas.
No! that's the point.
Ensembl Bio::Seq implementing objects can be used as read-only from the
SeqCanvas currently (though it looks weird right because of the way
Ensembl does this). But Ensembl has *no ability* to execute a
You have to make an in-memory copy to an implementation that works with
the update policy of the way SeqCanvas works. Lets keep these things
Would making a Bio::Seq::UpdateableSeq and possibly a
Bio::Seq::UpdateableSeqI be an ok route for you?
I just want to make sure that Bio::Seq stays as simple as possible. Update
policy is *never* simple.