[ensembl-dev] VEP cache and plugin interaction

Will McLaren wm2 at ebi.ac.uk
Mon Sep 24 12:07:06 BST 2012


Hi Allison,

Sorry for not getting back to you sooner.

Since you're looking at plugins I'll assume I can talk technical with
you! The cache stores serialised objects that have been retrieved from
the database. In order to minimise the size of the cache download, the
VEP strips some data from each of the objects before they are
serialised to disk. In the case of DBEntries, some are actually
explicitly cached on the transcript object by the VEP before
serialisation, since they are required by various VEP options;
examples are CCDS and HGNC identifiers. Others are forcibly removed
and so you will not find them if you try to retrieve them from a
cached object such as a transcript.

If you want access to things like the DBEntries, the best thing to do
would be to reload a copy of the object in question from the database
if required - simply use the transcript adaptor (stored as
$config->{ta}) and the method fetch_by_stable_id() using the stable_id
of your cached object.

I understand this is not ideal; for future releases I will look into
how much difference it makes to retain the DBEntries and other
datatypes that may be required by plugins.

Thanks for your query

Will McLaren
Ensembl Variation

On 21 September 2012 20:15, Allison Regier <aregier at genome.wustl.edu> wrote:
> Dear all,
> Can you clarify the interaction between VEP plugins and the cache?  Here is what I am seeing:
> I wrote a plugin that accesses $transcript->get_all_DBEntries().  When I run with the cache on (--cache option when running VEP), this method seems to not return anything.  However, with the cache turned off (no --cache option), the method returns db entries as expected.
> Is this the expected behavior?  Is there any workaround to allow VEP to use the cache when possible but access the database if necessary for API calls in the plugin?
> I am using Ensembl 67 and vep 2.5.
> thanks,
>
> Allison Regier
>
> The Genome Institute
> Washington University in St Louis
> _______________________________________________
> 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/




More information about the Dev mailing list