[ensembl-dev] Load homo_sapiens_core_83_37 and homo_sapiens_core_83_38 databases on same sql server?

[mag]

Hi Luke,

The registry can only deal with one core database for one species and 
release at a time.
It currently does not distinguish based on the assembly.
So if you use the API with the registry 
($registry->load_registry_from_db), you will not be able to have two 
versions of the same species database.

However, if you explicitly connect to one database, it is possible.
For example:
my $dba = Bio::EnsEMBL::DBSQL::DBAdaptor->new(
    -HOST => 'ensembldb.ensembl.org',
    -PORT => 3306,
    -USER => 'anonymous',
    -SPECIES => 'homo_sapiens_38',
    -DBNAME => 'homo_sapiens_core_84_38',
    -GROUP => 'core'
);
will create a database adaptor for the GRCh38 human database.
and
my $dba = Bio::EnsEMBL::DBSQL::DBAdaptor->new(
    -HOST => 'ensembldb.ensembl.org',
    -PORT => 3337,
    -USER => 'anonymous',
    -SPECIES => 'homo_sapiens_37',
    -DBNAME => 'homo_sapiens_core_84_37',
    -GROUP => 'core'
);
will create a database adaptor for the GRCh37 human database.
You can then use both databases within the same code.

Note here that I named the species homo_sapiens_38 and homo_sapiens_38, 
otherwise the new adaptor will supersed the old one.
Similarly, if you also have a load_registry_from_db call in your code, 
this will have already loaded a human core database and that will be the 
one used by default.

If you do not use the two databases within the same code, you can simply 
keep the homo_sapiens species alias, although again, without another 
load_registry_from_db call.


Hope that helps,
Magali

On 14/03/2016 20:46, Luke Goodsell wrote:
> Hi,
>
> Is it possible to load both the same releases of the GRCh37 and GRCh38 EnsEMBL databases on the same server and choose which assembly to use in the Perl API? We currently have them running on different mysqld instances, but this is undesirable.
>
> I understand I could keep release n of 38 and release n-1 of 37, and load the corresponding perl modules, but this would quickly become a nightmare to maintain as new releases come out.
>
> Kind regards,
> Luke
>
>
>
>
> _______________________________________________
> 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://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20160315/0208a8e5/attachment.html>