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