[BioSQL-l] Problem with Bio::DB::BioSQL::PrimarySeqAdapter

[Hilmar Lapp]

Great that it works.

The problem is I think that if for a persistent seq object the 
(non-persistent) delegate initiates a call to seq() then the 
persistence wrapper class isn't in the loop and so can't intercept it, 
unlike if you call $pseq->seq(). This nonetheless works for Bio::Seq 
objects because they delegate themselves to a PrimarySeq instance which 
is also persistence-wrapped.

I.e., just if you're curious you should be able to reproduce the 
problem even when using the Bio::SeqI adaptor if instead of calling 
$pseq->trunc() you call
$pseq->primary_seq->trunc() (and similarly for revcom()). (Don't bother 
trying if you don't care, really - this is mostly me thinking out loud 
:-)

I'm afraid this means that I need to override revcom() and trunc() in 
the persistence wrapper class for sequences. Not very beautiful, but 
will solve the problem.

	-hilmar

On May 27, 2005, at 3:37 AM, Roy Chaudhuri wrote:

>> Doesn't look immediately obvious what's going on but one suspicion I
>> have is that the sequence retrieval optimization is playing a role
>> here. The sequence of a db-retrieved entry is actually lazy-loaded,
>> i.e., only on demand. Theoretically, though, truncating or revcom'ing
>> the sequence should provide for the demand ...
>>
>> Can you try in your test script to print out $pseq before you truncate
>> and revcom it? I.e.,
>>
>> 	my $pseq=$objadap->find_by_query($query)->next_object;
>> 	print "\$pseq isa Bio::PrimarySeq\n" if 
>> $pseq->isa('Bio::PrimarySeq');
>> 	print $out $pseq;
>> 	my $ptrunc=$pseq->trunc(100,120);
>> 	my $prc=$pseq->revcom;
>> 	print $out $ptrunc, $prc;
>>
>> Does this yield a different result?
>
> Yes, that works as it should, correctly truncating and reverse
> complementing the sequence. Calling $pseq->seq in a void context before
> revcom/trunc is useful as a 'silent' workaround.
>
> Thanks.
> Roy.
>
> --
> Dr. Roy Chaudhuri
> Bioinformatics Research Fellow
> Division of Immunity and Infection
> University of Birmingham, UK
>
> http://colibase.bham.ac.uk
>
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------