[Bioperl-l] Bio::DB::GFF/Postgres test failures
Scott Cain
scott at scottcain.net
Mon Apr 11 17:27:34 UTC 2011
OK, I fixed the second bug I referred to below (and committed it on
master :-) If nobody complains, I also change the test I referred to
first below, and then my issues with the next release should be
resolved.
Thanks,
Scott
On Mon, Apr 11, 2011 at 11:53 AM, Scott Cain <scott at scottcain.net> wrote:
> The test I was complaining about last week is clearly flawed. I would
> suggest changing the "doesnotexit" to "-1" in this test:
>
> is( $db->fetch('doesnotexit'), undef);
>
> where the point of the test is to search for something by ID that
> doesn't exist. Since a primary key of "-1" is unlikely to be used
> with an autogenerated primary key, that should safely fail to find
> something, thus passing the test.
>
> There is, however, a second failure with the Pg test that I'm working
> on today, where for some reason, the same method in the mysql adaptor
> (inherited by the Pg adaptor) is generating different queries when run
> against the different databases. Once I sort out why that is
> happening, the Pg adaptor should be passing tests again.
>
> Scott
>
>
> On Mon, Apr 11, 2011 at 10:15 AM, Chris Fields <cjfields at illinois.edu> wrote:
>> Lincoln,
>>
>> It's Bio::Aseembly-specific incorrect semantics that are triggering this, I don't think anything in the SF::Store/GBrowse set triggers the problem. So, to me this isn't a blocker for anything unless someone specifies that Bio::Assembly must use the Pg adaptor (I think it uses the memory one by default, not sure if it's hard-coded that way).
>>
>> I do agree with Scott, that MySQL and other adaptors are silently dealing with this data w/o dying, so this should be filed for tracking, as I'm sure it will pop up at some point again. The relevant tests should be TODO'd to catch this.
>>
>> Since this will likely be the last release for 1.6.x, I suppose we can go ahead and leave the version number as 1.0069.
>>
>> chris
>>
>> On Apr 10, 2011, at 4:10 PM, Lincoln Stein wrote:
>>
>>> Hi Folks,
>>>
>>> Is this what's blocking the netx bioperl release, or are there other
>>> blockers?
>>>
>>> I just released GBrowse 2.27, which requires bioperl 1.0069 or higher.
>>>
>>> Lincoln
>>>
>>> On Fri, Apr 8, 2011 at 8:53 PM, Chris Fields <cjfields at illinois.edu> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> 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>
>>> _______________________________________________
>>> 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
>
--
------------------------------------------------------------------------
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