[BioSQL-l] bioperl-db bugs

[Chris Fields]

Hilmar,

I think I have two bioperl-db bugs sorted out, but I'm trying to  
determine whether the solution is a side-effect, a feature, or a bug.   
Dmitry has filed two bug reports which are somewhat related:

http://bugzilla.open-bio.org/show_bug.cgi?id=2280
http://bugzilla.open-bio.org/show_bug.cgi?id=2281

I have added my comments to it, but maybe you can shed some more light  
on this.  What he is trying to do is copy a persistent Seq object to a  
different namespace; load_seqdatabase.pl won't let him do that  
directly using the same sequence file.  If he changes the namespace()  
and store()s it using a script, the seq is moved to the new namespace,  
not updated.

My reasoning is this is a feature (by not changing the primary_key,  
you don't store a new sequence but update the current one).  However,  
if the primary_key is unset (undef), then it appears you can copy the  
sequence over (from Dmitry's script, with my addition noted):

...
my $ns1 = 'space1';
my $ns2 = 'space2';

my $seqadp = $db->get_object_adaptor('Bio::SeqI');
my $aux_seq = Bio::Seq::RichSeq->new(
     -accession_number => 'NC_005982',
     -version => 1,
     -namespace => $ns1);
my $seq = $seqadp->find_by_unique_key($aux_seq);

# store the found sequence in the second biodatabase:
my $pseq = $seqadp->create_persistent($ns2);
$pseq->namespace('bioperl2');
$pseq->primary_key(undef);  # my addition, which appears to work
$pseq->store();
$seqadp->commit;
...

My question: is this an intended effect?  The ability to assign undef  
to primary_key seems intentional based on the method code, but I'm a  
bit uncertain here.

chris