<div dir="ltr"><div><br></div><div>Please unsubscribe to this emails.</div><div>Thanks</div><div>Vin</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 23, 2014 at 2:41 AM, <span dir="ltr"><<a href="mailto:dev-request@ensembl.org" target="_blank">dev-request@ensembl.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send Dev mailing list submissions to<br>
<a href="mailto:dev@ensembl.org">dev@ensembl.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:dev-request@ensembl.org">dev-request@ensembl.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:dev-owner@ensembl.org">dev-owner@ensembl.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of Dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Variation set: fetch_all_by_Variation() outputting hash<br>
values (Gong, Henry)<br>
2. Re: REST server 3.0 vep endopoint works only with human<br>
specie (Paolo Cozzi)<br>
3. Re: REST server 3.0 vep endopoint works only with human<br>
specie (mag)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 22 Jul 2014 22:42:09 +0000<br>
From: "Gong, Henry" <<a href="mailto:Henry.Gong@ucsf.edu">Henry.Gong@ucsf.edu</a>><br>
Subject: [ensembl-dev] Variation set: fetch_all_by_Variation()<br>
outputting hash values<br>
To: "<a href="mailto:dev@ensembl.org">dev@ensembl.org</a>" <<a href="mailto:dev@ensembl.org">dev@ensembl.org</a>><br>
Message-ID: <<a href="mailto:3171BB1BB8CFE243921782339B59966384628F@ex07.net.ucsf.edu">3171BB1BB8CFE243921782339B59966384628F@ex07.net.ucsf.edu</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
Hi Anja,<br>
<br>
It looks like I had assumed that simply calling VariationSet would produce a name, similar to<br>
my @vstates = @{$tva->variation_feature->get_all_validation_states()};<br>
print<br>
"\t",join(",", @vstates); #evidence<br>
Though I see now that an evidence value is qualitatively different from a variation set.<br>
I don't intend on calling all the variations per set; my application is only looking at potentially hundreds (per transcript or per gene), but I'll consider using iterators to save a little memory.<br>
<br>
I added your suggestion as<br>
foreach my $tva(@{$tvas}) {<br>
my @vsets = @{$vs_adaptor->fetch_all_by_Variation($tva->variation_feature->variation)};<br>
print $tva->variation_feature->display_id, "\t";<br>
foreach my $vs(@vsets) {<br>
my $set_name = $vs->name();<br>
print $set_name,",";<br>
}<br>
print "\n";<br>
}<br>
and it does indeed work!<br>
<br>
Thanks,<br>
Henry Gong<br>
Junior Specialist<br>
UCSF Dept of Neuro Surgery<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.ensembl.org/pipermail/dev/attachments/20140722/677c68d3/attachment-0001.htm" target="_blank">http://lists.ensembl.org/pipermail/dev/attachments/20140722/677c68d3/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 23 Jul 2014 11:14:51 +0200<br>
From: Paolo Cozzi <<a href="mailto:paolo.cozzi@itb.cnr.it">paolo.cozzi@itb.cnr.it</a>><br>
Subject: Re: [ensembl-dev] REST server 3.0 vep endopoint works only<br>
with human specie<br>
To: <a href="mailto:dev@ensembl.org">dev@ensembl.org</a><br>
Message-ID: <<a href="mailto:53CF7D0B.1030408@itb.cnr.it">53CF7D0B.1030408@itb.cnr.it</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
<br>
Dear Magali,<br>
<br>
Thank you for your replay and your support. Could you describe briefly<br>
vep cache? is something like memcached?<br>
<br>
At the moment, I don't think that I need faster performance on other<br>
species, but I will remember your suggestion.<br>
<br>
Regards,<br>
<br>
Paolo.<br>
<br>
<br>
<br>
Il 22/07/2014 18:36, mag ha scritto:<br>
> Hi Paolo,<br>
><br>
> Thank you for reporting this and apologies for the error.<br>
><br>
> We were wrongly using some human-specific configuration for all<br>
> species, this has now been fixed on the live server.<br>
><br>
> If you are using POST requests for VEP, please be aware that only<br>
> human uses the vep cache.<br>
> For other species, we are still using direct database connection,<br>
> which will result in lower performance.<br>
><br>
> If you are interested in getting faster POST support for other<br>
> species, please contact us.<br>
><br>
><br>
> Regards,<br>
> Magali<br>
><br>
> On 22/07/2014 11:55, Paolo Cozzi wrote:<br>
>><br>
>> Dear developer,<br>
>><br>
>> I found an odd response from the vep/:species/region/<br>
>> <<a href="http://rest.ensembl.org/documentation/info/vep_region_post" target="_blank">http://rest.ensembl.org/documentation/info/vep_region_post</a>> of the<br>
>> new ensembl REST server ( <a href="http://rest.ensembl.org/" target="_blank">http://rest.ensembl.org/</a>) while searching<br>
>> for species other than human. For example, if I do 2 POST request<br>
>> with curl on human and cow (the sample data are the same as in the<br>
>> VEP webserver):<br>
>><br>
>> $ curl -H "content-type:application/json" -H<br>
>> "accept:application/json" --data '{ "variants" : ["1 909238 909238<br>
>> G/C +", "3 361464 361464 A/- +", "5 121187650 121188519 DUP"]<br>
>> }' <a href="http://rest.ensembl.org/vep/human/region" target="_blank">http://rest.ensembl.org/vep/human/region</a> > output_human.txt<br>
>><br>
>> $ curl -H "content-type:application/json" -H<br>
>> "accept:application/json" --data '{ "variants" : ["1 909238 909238<br>
>> G/C +", "3 361464 361464 A/- +", "5 121187650 121188519 DUP"]<br>
>> }' <a href="http://rest.ensembl.org/vep/cow/region" target="_blank">http://rest.ensembl.org/vep/cow/region</a> > output_cow.txt<br>
>><br>
>> I will find the same results (diff give me no output), even VEP gives<br>
>> me 2 different results. Could be a problem of variation endpoint?<br>
>><br>
>> Thanks for your support,<br>
>><br>
>> best regards,<br>
>><br>
>> Paolo.<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Dev mailing <a href="mailto:listDev@ensembl.org">listDev@ensembl.org</a><br>
>> Posting guidelines and subscribe/unsubscribe info:<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>> Ensembl Blog:<a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Dev mailing list <a href="mailto:Dev@ensembl.org">Dev@ensembl.org</a><br>
> Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
> Ensembl Blog: <a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.ensembl.org/pipermail/dev/attachments/20140723/9426f4e5/attachment-0001.htm" target="_blank">http://lists.ensembl.org/pipermail/dev/attachments/20140723/9426f4e5/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Wed, 23 Jul 2014 10:41:25 +0100<br>
From: mag <<a href="mailto:mr6@ebi.ac.uk">mr6@ebi.ac.uk</a>><br>
Subject: Re: [ensembl-dev] REST server 3.0 vep endopoint works only<br>
with human specie<br>
To: <a href="mailto:dev@ensembl.org">dev@ensembl.org</a><br>
Message-ID: <<a href="mailto:53CF8345.4050104@ebi.ac.uk">53CF8345.4050104@ebi.ac.uk</a>><br>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<br>
<br>
Hi Paolo,<br>
<br>
The variation provides a vep cache for all species with variation data<br>
<a href="ftp://ftp.ensembl.org/pub/release-75/variation/VEP/" target="_blank">ftp://ftp.ensembl.org/pub/release-75/variation/VEP/</a><br>
<br>
This cache contains all known variations, ordered by location.<br>
Combined with a fasta file for the genomic sequence, this means we can<br>
access all the required information from file rather than querying the<br>
database every time.<br>
<br>
With single queries, the performance is comparable.<br>
If you are running multiple queries, especially if you are working on<br>
the same region, the file retrieval is faster as it can re-use indexed data.<br>
<br>
<br>
Regards,<br>
Magali<br>
<br>
On 23/07/2014 10:14, Paolo Cozzi wrote:<br>
><br>
> Dear Magali,<br>
><br>
> Thank you for your replay and your support. Could you describe briefly<br>
> vep cache? is something like memcached?<br>
><br>
> At the moment, I don't think that I need faster performance on other<br>
> species, but I will remember your suggestion.<br>
><br>
> Regards,<br>
><br>
> Paolo.<br>
><br>
><br>
><br>
> Il 22/07/2014 18:36, mag ha scritto:<br>
>> Hi Paolo,<br>
>><br>
>> Thank you for reporting this and apologies for the error.<br>
>><br>
>> We were wrongly using some human-specific configuration for all<br>
>> species, this has now been fixed on the live server.<br>
>><br>
>> If you are using POST requests for VEP, please be aware that only<br>
>> human uses the vep cache.<br>
>> For other species, we are still using direct database connection,<br>
>> which will result in lower performance.<br>
>><br>
>> If you are interested in getting faster POST support for other<br>
>> species, please contact us.<br>
>><br>
>><br>
>> Regards,<br>
>> Magali<br>
>><br>
>> On 22/07/2014 11:55, Paolo Cozzi wrote:<br>
>>><br>
>>> Dear developer,<br>
>>><br>
>>> I found an odd response from the vep/:species/region/<br>
>>> <<a href="http://rest.ensembl.org/documentation/info/vep_region_post" target="_blank">http://rest.ensembl.org/documentation/info/vep_region_post</a>> of the<br>
>>> new ensembl REST server ( <a href="http://rest.ensembl.org/" target="_blank">http://rest.ensembl.org/</a>) while searching<br>
>>> for species other than human. For example, if I do 2 POST request<br>
>>> with curl on human and cow (the sample data are the same as in the<br>
>>> VEP webserver):<br>
>>><br>
>>> $ curl -H "content-type:application/json" -H<br>
>>> "accept:application/json" --data '{ "variants" : ["1 909238 909238<br>
>>> G/C +", "3 361464 361464 A/- +", "5 121187650 121188519 DUP"]<br>
>>> }' <a href="http://rest.ensembl.org/vep/human/region" target="_blank">http://rest.ensembl.org/vep/human/region</a> > output_human.txt<br>
>>><br>
>>> $ curl -H "content-type:application/json" -H<br>
>>> "accept:application/json" --data '{ "variants" : ["1 909238 909238<br>
>>> G/C +", "3 361464 361464 A/- +", "5 121187650 121188519 DUP"]<br>
>>> }' <a href="http://rest.ensembl.org/vep/cow/region" target="_blank">http://rest.ensembl.org/vep/cow/region</a> > output_cow.txt<br>
>>><br>
>>> I will find the same results (diff give me no output), even VEP<br>
>>> gives me 2 different results. Could be a problem of variation endpoint?<br>
>>><br>
>>> Thanks for your support,<br>
>>><br>
>>> best regards,<br>
>>><br>
>>> Paolo.<br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Dev mailing <a href="mailto:listDev@ensembl.org">listDev@ensembl.org</a><br>
>>> Posting guidelines and subscribe/unsubscribe info:<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>>> Ensembl Blog:<a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Dev mailing <a href="mailto:listDev@ensembl.org">listDev@ensembl.org</a><br>
>> Posting guidelines and subscribe/unsubscribe info:<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
>> Ensembl Blog:<a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Dev mailing <a href="mailto:listDev@ensembl.org">listDev@ensembl.org</a><br>
> Posting guidelines and subscribe/unsubscribe info:<a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
> Ensembl Blog:<a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.ensembl.org/pipermail/dev/attachments/20140723/f80b2a77/attachment.htm" target="_blank">http://lists.ensembl.org/pipermail/dev/attachments/20140723/f80b2a77/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
Dev mailing list <a href="mailto:Dev@ensembl.org">Dev@ensembl.org</a><br>
Posting guidelines and subscribe/unsubscribe info: <a href="http://lists.ensembl.org/mailman/listinfo/dev" target="_blank">http://lists.ensembl.org/mailman/listinfo/dev</a><br>
Ensembl Blog: <a href="http://www.ensembl.info/" target="_blank">http://www.ensembl.info/</a><br>
<br>
<br>
End of Dev Digest, Vol 49, Issue 18<br>
***********************************<br>
</blockquote></div><br></div>