[Bioperl-l] Opening up deleting features from Seq objects again

[Ewan Birney]

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

   Bio::Seq::UpdateableSeq

   
> 
> > 
> > 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
split.


> 
> >   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
delete_feature.


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
separate. 



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.