[ensembl-dev] api v60 to v62

Wed Sep 28 12:52:39 BST 2011

Hi Graham,

I now have this same issue with one variant (13,39618302,T/G,+) when
using the newest ensembl api. 

Exact error:
Can't call method "display_term" on an undefined value at
/data/common_modules/ensembl64/ensembl-variation/modules/Bio/EnsEMBL/Variation/VariationFeatureOverlap.pm
line 594.

Caused by this line in my code:
$transcript_variation->display_consequence; # only most severe effect

In the VEP online output (which does work) the transcript
ENST00000537150 is the one causing trouble, it doesn't have a
consequence.

Thanks,
Stef

----- Original message -----
From: "Jan Vogel" <jan.vogel at gmail.com>
To: "Graham Ritchie" <grsr at ebi.ac.uk>
Cc: "Kim Brugger" <kb468 at cam.ac.uk>, mailsvl at fastmail.fm, "Ensembl
DevList" <dev at ensembl.org>
Date: Fri, 8 Jul 2011 09:56:36 -0700
Subject: Re: [ensembl-dev] api v60 to v62

Thanks Graham !!! 

On Jul 8, 2011, at 8:45 AM, Graham Ritchie wrote:

> Hi all,
> 
> I have just committed some changes to the release 63 CVS repository that should fix this issue, the problem was down to some confusion on my part about relative vs. absolute coordinates that our testing did not discover. You can now disregard any previous emails with work-arounds from me. I would appreciate any feedback on any further issues you find with this code, and indeed if it addresses the various problems you have encountered with this part of the API.
> 
> Sorry for any hassle caused by these changes, but we hope that the new code offers useful features and we will try to do more to ensure backwards compatibility going forward.
> 
> Cheers,
> 
> Graham
> 
> Ensembl Variation
> 
> 
> On 8 Jul 2011, at 11:53, Kim Brugger wrote:
> 
>> I ended up rewriting our whole variation annotation pipeline as it seemed faster. This was mainly due to the changes to the API, but also because as I wanted to use some of the new features.
>> 
>> /kim
>> 
>> On 08/07/11 11:26, mailsvl at fastmail.fm wrote:
>>> Hi Jan,
>>> 
>>> Well, to be honest I've been quite busy with other things and left it
>>> for now (so still using ensembl 60), since the cause of the issue isn't
>>> entirely clear yet. But I am certainly planning to make it work soon
>>> (perhaps for v63 :P) But, Graham responded as shown below. Maybe it
>>> helps you or maybe Graham has some more information on this now..?
>>> 
>>> Cheers,
>>> Stef
>>> 
>>> ############# Reply Graham #############
>>> 
>>> Hi Stef,
>>> 
>>> Sorry for the delay in getting back to you, this issue is proving quite
>>> tricky! I haven't yet got a proper solution but I'm working with the
>>> core team to try to establish the root cause.
>>> 
>>> In the mean time, if you need to get this working for now, I have come
>>> up with a work-around which seems to get your script working again. If
>>> you change the code at line 382 in
>>> ensembl-variation/modules/Bio/EnsEMBL/Variation/VariationFeature.pm
>>> from:
>>> 
>>> $transcripts = [ map { $_->transfer($self->slice) } @{
>>> $slice->get_all_Transcripts } ];
>>> 
>>> to the following 2 lines:
>>> 
>>> my $toplevel_slice = $self->slice->adaptor->fetch_by_region('toplevel',
>>> $self->slice->seq_region_name);
>>> $transcripts = [ map { $_->transfer($toplevel_slice) } @{
>>> $slice->get_all_Transcripts } ];
>>> 
>>> your script should work again. I have also attached a copy of the module
>>> with the fix in it to this email. This work-around addresses the fact
>>> that the TranscriptMapper module from the core API, which we use in
>>> several places in the consequence calculation code, does not seem to
>>> cope with slices that are much smaller than the transcript, as in your
>>> script where you have a slice which is a single base pair long. An
>>> alternative work-around that would involve changing your script would be
>>> to create your VariationFeatures on a chromosomal slice and then set the
>>> start and end coordinates to chromosomal coordinates.
>>> 
>>> I haven't tested this fix much, so if you get any further odd results,
>>> or you get very different output to API v60, please let me know. I will
>>> let you know as and when we have come up with a proper fix for this
>>> issue.
>>> 
>>> Cheers,
>>> 
>>> Graham
>>> 
>>> ############# /Reply Graham ############
>>> 
>>> 
>>> 
>>> ----- Original message -----
>>> From: "Jan Vogel"<jan.vogel at gmail.com>
>>> To: "Graham Ritchie"<grsr at ebi.ac.uk>
>>> Cc: mailsvl at fastmail.fm, "Ensembl DevList"<dev at ensembl.org>
>>> Date: Thu, 7 Jul 2011 19:29:38 -0700
>>> Subject: Re: [ensembl-dev] api v60 to v62
>>> 
>>> 
>>> Hi Stef&  Graham,
>>> 
>>> did you manage to solve this issue ? I'm running in the same trouble
>>> here with e62 and e63 checkouts.
>>> 
>>> Jan
>>> 
>>> On Jun 24, 2011, at 7:23 AM, mailsvl at fastmail.fm wrote:
>>> 
>>>> Hi everyone,
>>>> 
>>>> We have a script based on ensembl api v60 (where it works without
>>>> errors) and it almost runs flawless with v62 as well except for one
>>>> error:
>>>> 
>>>> Can't call method "display_term" on an undefined value at
>>>> /data/common_modules/ensembl62/ensembl-variation/modules/Bio/EnsEMBL/Variation/VariationFeatureOverlap.pm
>>>> line 530.
>>>> 
>>>> If I remove this call/line everything runs fine:
>>>> 
>>>> $consequence = $transcript_variation->display_consequence if defined
>>>> $transcript_variation->display_consequence;
>>>> 
>>>> ...but then I'm left without the consequences so thats not really an
>>>> option ;) Anyone knows what change from v60 to v62 makes this method now
>>>> run into problems?
>>>> 
>>>> Thanks!
>>>> Stef
>>>> __________________
>>>> http://www.fastmail.fm
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Dev mailing list    Dev at ensembl.org
>>>> List admin (including subscribe/unsubscribe): http://lists.ensembl.org/mailman/listinfo/dev
>>>> Ensembl Blog: http://www.ensembl.info/
>>> On Jun 24, 2011, at 8:31 AM, Graham Ritchie wrote:
>>> 
>>>> Hi Stef,
>>>> 
>>>> This part of the variation API changed quite a lot under the hood for v62, and we did try to maintain the same interface, but you may have found somewhere where the interface has changed. If you could send me a copy of the script, or even just a minimal script that exhibits the same bug, I will be able to try to establish the problem much more quickly.
>>>> 
>>>> Cheers,
>>>> 
>>>> Graham
>>>> 
>>>> 
>>>> On 24 Jun 2011, at 15:23, mailsvl at fastmail.fm wrote:
>>>> 
>>>>> Hi everyone,
>>>>> 
>>>>> We have a script based on ensembl api v60 (where it works without
>>>>> errors) and it almost runs flawless with v62 as well except for one
>>>>> error:
>>>>> 
>>>>> Can't call method "display_term" on an undefined value at
>>>>> /data/common_modules/ensembl62/ensembl-variation/modules/Bio/EnsEMBL/Variation/VariationFeatureOverlap.pm
>>>>> line 530.
>>>>> 
>>>>> If I remove this call/line everything runs fine:
>>>>> 
>>>>> $consequence = $transcript_variation->display_consequence if defined
>>>>> $transcript_variation->display_consequence;
>>>>> 
>>>>> ...but then I'm left without the consequences so thats not really an
>>>>> option ;) Anyone knows what change from v60 to v62 makes this method now
>>>>> run into problems?
>>>>> 
>>>>> Thanks!
>>>>> Stef
>>>>> __________________
>>>>> http://www.fastmail.fm
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Dev mailing list    Dev at ensembl.org
>>>>> List admin (including subscribe/unsubscribe): http://lists.ensembl.org/mailman/listinfo/dev
>>>>> Ensembl Blog: http://www.ensembl.info/
>>>> 
>>>> _______________________________________________
>>>> Dev mailing list    Dev at ensembl.org
>>>> List admin (including subscribe/unsubscribe): http://lists.ensembl.org/mailman/listinfo/dev
>>>> Ensembl Blog: http://www.ensembl.info/
>>> __________________
>>> http://www.fastmail.fm
>>> 
>>> 
>>> _______________________________________________
>>> Dev mailing list    Dev at ensembl.org
>>> List admin (including subscribe/unsubscribe): http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog: http://www.ensembl.info/
>> 
>> 
>> -- 
>> ==========================================================
>> Kim Brugger
>> EASIH, University of Cambridge
>> www.easih.ac.uk
>> ==========================================================
> 