[Bioperl-l] Bio::DB::GFF/Postgres test failures
Scott Cain
scott at scottcain.net
Fri Apr 8 21:32:50 UTC 2011
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
More information about the Bioperl-l
mailing list