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

Chris Fields cjfields at illinois.edu
Mon Apr 11 17:35:58 UTC 2011 

Scott,

Go ahead and change the test if you haven't done it already.  The only blocker would be the Module::Build work I alluded to earlier, which I'm working on now.

Lincoln, probably not necessary to worry about changing the version number for the GBrowse release, we can deal with bug fixes with minor version increments on 1.6.9.  Most end-users won't care about versioning anyway as long as the dependency install path works fine.

chris

On Apr 11, 2011, at 12:27 PM, Scott Cain wrote:

> 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
> 
> _______________________________________________
> 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