[Bioperl-l] Bio::DB::GFF/Postgres test failures

Chris Fields cjfields at illinois.edu
Sat Apr 9 00:53:59 UTC 2011


That was introduced here by Florent:

https://github.com/bioperl/bioperl-live/commit/6f65223ef5aabc3ceaa815d3cb71982f81ae6b30#t/LocalDB/SeqFeature.t

So, essentially the MySQL adaptor is getting this wrong.  Any way we can somehow enable strict mode?

http://dev.mysql.com/doc/refman/5.0/en/server-sql-mode.html

chris

On Apr 8, 2011, at 4:32 PM, Scott Cain wrote:

> Argh!  MySQL is not a RDMS!  Anyone who tells you otherwise is lying!
> 
> The first test failure for the Pg SFS adaptor is failing because it is
> trying to execute this query (which it inherited from the mysql
> adaptor, where it works just fine):
> 
>  select id,object FROM bioperl_seqfeature_t_test_schema_feature where
> id='doesnotexit';
> 
> Of course, the id column is defined as an integer column.  MySQL must
> be silently casting this string to an integer value (? I guess
> anyway--who knows).  Anyway, PostgreSQL does the right thing and
> throws an error with this query.  I don't see how I can make the
> Postgres adaptor pass this test as written, as it is nonsensical.
> 
> Scott
> 
> 
> 
> On Fri, Apr 8, 2011 at 2:56 PM, Chris Fields <cjfields at illinois.edu> wrote:
>> Scott,
>> 
>> I'll try documenting the Pg error for SF::Store in the next hour.  Had my hands full with the GSoC onslaught of emails and local $job stuff.  Would like to get it fixed for the CPAN release.
>> 
>> chris
>> 
>> On Apr 8, 2011, at 12:58 PM, Scott Cain wrote:
>> 
>>> OK, I'll take it out and move on to the next problem.
>>> 
>>> Thanks,
>>> Scott
>>> 
>>> 
>>> On Fri, Apr 8, 2011 at 1:51 PM, Lincoln Stein <lincoln.stein at gmail.com> wrote:
>>>> Oh right. The Bio::DB::GFF adaptor has that broken behavior and it is too
>>>> late to change it now. (Bio::DB::SeqFeature::Store had better not!) Best to
>>>> remove the test altogether.
>>>> Lincoln
>>>> 
>>>> On Fri, Apr 8, 2011 at 1:18 PM, Scott Cain <scott at scottcain.net> wrote:
>>>>> 
>>>>> Hi Lincoln,
>>>>> 
>>>>> Yes, apparently, it does.  It does this for both the memory and the
>>>>> postgres adaptors.  I looked at how the data was stored in the feature
>>>>> object with Data::Dumper and that is how it is represented in the hash
>>>>> too.  Perhaps this test should be calling the "absolute" method first?
>>>>> 
>>>>> Scott
>>>>> 
>>>>> 
>>>>> On Fri, Apr 8, 2011 at 1:10 PM, Lincoln Stein <lincoln.stein at gmail.com>
>>>>> wrote:
>>>>>> Do start() and end() flip values for minus strand features? This isn't
>>>>>> supposed to happen.
>>>>>> Lincoln
>>>>>> 
>>>>>> On Fri, Apr 8, 2011 at 11:41 AM, Scott Cain <scott at scottcain.net> wrote:
>>>>>>> 
>>>>>>> Hi Lincoln,
>>>>>>> 
>>>>>>> I've been looking into some test failures with the postgres adaptor
>>>>>>> for Bio::DB::GFF and I wanted to check with you that I'm interpreting
>>>>>>> this correctly.  In t/LocalDB/BioDBGFF.t there are these lines:
>>>>>>> 
>>>>>>>  @features = sort {$a->start<=>$b->start} @features;
>>>>>>> 
>>>>>>>  is($features[0]->type,'Component:reference');
>>>>>>>  is($features[-1]->type,'exon:confirmed');
>>>>>>> 
>>>>>>> So that the features in the data set are sorted by their start values
>>>>>>> and the beginning and end of the list are checked.  The test refers to
>>>>>>> the test.gff data file, that contains among others these lines:
>>>>>>> 
>>>>>>> Contig1 confirmed   transcript      30001   31000   .   -   .
>>>>>>> Transcript trans-2; Gene "xyz-2"; Note "Terribly interesting"
>>>>>>> Contig1 confirmed   exon    30001   30100   .   -   .   Transcript
>>>>>>> trans-2; Gene "abc-1"; Note "function unknown"
>>>>>>> Contig1 confirmed   exon    30701   30800   .   -   .   Transcript
>>>>>>> trans-2
>>>>>>> Contig1 confirmed   exon    30801   31000   .   -   .   Transcript
>>>>>>> trans-2
>>>>>>> 
>>>>>>> Since this transcript and its exons are on the minus strand, the
>>>>>>> values that the start and stop method return will be reversed, so that
>>>>>>> start for the transcript will be 31000 and stop will be 30001.  The
>>>>>>> problem with this test is since the last exon and the transcript share
>>>>>>> a start value (31000), you can't really be sure which one will be at
>>>>>>> the bottom of the list after sorting, right?  In the case of the
>>>>>>> postgres adaptor, it fails this test on my machine because the
>>>>>>> transcript is at the bottom of the list.  The test for the beginning
>>>>>>> of the list similarly could fail though it didn't in my case, as other
>>>>>>> features that have 1 as a start are of type "Component:clone".
>>>>>>> 
>>>>>>> So, my question is this: am I missing something, and the postgres
>>>>>>> adaptor is not behaving as expected, or are these tests ambiguous?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Scott
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> ------------------------------------------------------------------------
>>>>>>> Scott Cain, Ph. D.                                   scott at scottcain
>>>>>>> dot net
>>>>>>> GMOD Coordinator (http://gmod.org/)                     216-392-3087
>>>>>>> Ontario Institute for Cancer Research
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Lincoln D. Stein
>>>>>> Director, Informatics and Biocomputing Platform
>>>>>> Ontario Institute for Cancer Research
>>>>>> 101 College St., Suite 800
>>>>>> Toronto, ON, Canada M5G0A3
>>>>>> 416 673-8514
>>>>>> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> ------------------------------------------------------------------------
>>>>> Scott Cain, Ph. D.                                   scott at scottcain
>>>>> dot net
>>>>> GMOD Coordinator (http://gmod.org/)                     216-392-3087
>>>>> Ontario Institute for Cancer Research
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Lincoln D. Stein
>>>> Director, Informatics and Biocomputing Platform
>>>> Ontario Institute for Cancer Research
>>>> 101 College St., Suite 800
>>>> Toronto, ON, Canada M5G0A3
>>>> 416 673-8514
>>>> Assistant: Renata Musa <Renata.Musa at oicr.on.ca>
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> ------------------------------------------------------------------------
>>> Scott Cain, Ph. D.                                   scott at scottcain dot net
>>> GMOD Coordinator (http://gmod.org/)                     216-392-3087
>>> Ontario Institute for Cancer Research
>>> 
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>> 
>> 
> 
> 
> 
> -- 
> ------------------------------------------------------------------------
> Scott Cain, Ph. D.                                   scott at scottcain dot net
> GMOD Coordinator (http://gmod.org/)                     216-392-3087
> Ontario Institute for Cancer Research
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l





More information about the Bioperl-l mailing list