GitLab

tell the user whether to update the code to match the database SQL schema version, or which SQL patches to apply to the database

use SqlSchemaAdaptor to detect the current code's sql version and record it in 'hive_meta' (leave it out of tables.*sql* files)

A new "adaptor" for detection of software's sql version based on the number of available sql patches.

move Core 'schema_version' out of tables.* files into HiveGeneric_conf (via ApiVersion), expose it for manipulation and make it available to PipeConfigs

new 'hive_meta' table to keep hive_sql_schema_version (=number of patches), hive_pipeline_name and hive_use_triggers

Changed an 'our' global variable to ENV{EHIVE_ROOT_DIR} to allow API-only users to set it and work as usual

bugfix: make sure users' tweaking of Data::Dumper::Maxdepth does not mess up stringify()' s operation

Utils/Config.pm no longer depends on ENSEMBL_CVS_ROOT_DIR, which becomes non-essential for non-EnsEMBL applications.

cosmetic: added short summary of Git commits between 23.Apr-14.Jun'2013 to Changelog for CVS-only users

PostgreSQL: connection parameters are now supplied on the command line (no need to set PG variables by hand)

given -job_id Scheduler should take the Analysis into account and only submit a Worker for this Analysis

Adding foreign keys to PostgreSQL schema by reusing the MySQL file (the syntax happens to be exactly the same!)

Has one known limitation (always INSERTs instead of INSERT_IGNORE and REPLACE) and may contain other bugs.

Slow the example down a bit and allow 2 Workers. In "-can_specialize 1" mode the two Workers will complete the whole pipeline.

setting "-hive_force_init 1" will cause init_pipeline.pl to drop the database prior to creation (use with care!)