GitLab

The last time we ran patch_test_databases for release 98 it somehow managed
to apply compara's patch_97_98_b without applying patch_97_98_a. I don't
even.

Source: release/98 branch of ols-ensembl-loader and master branches
of all other relevant Ensembl repositories, pulled a few minutes ago.
Compara, Variation and ontology schemas all have already been bumped to
version 98.

ENSCORESW-3132: Limited implementation of Intervals with start > end (i.e. spanning the origin of a circular chromosome)

Code updated to implement review comments. There is a new package to handle stop codon readthrough in a sequence. Test case has been updated with new regex

The previous test-database update missed some patches for the core and
variation schemas, which is why Travis jobs keep failing these days.

ENSCORESW-3110- Code to handle stop codon readthrough in 12 transcripts. The code edits the amino acid sequence to display the stop codon readthrough with an X

Code updated to implement review comments. There is a new package to handle stop codon readthrough in a sequence. Test case has been updated with new regex

The previous test-database update missed some patches for the core and
variation schemas, which is why Travis jobs keep failing these days.

ENSCORESW-3110- Code to handle stop codon readthrough in 12 transcripts. The code edits the amino acid sequence to display the stop codon readthrough with an X

See ENSCORESW-3054. Only really affects the test suite at this point,
in the code proper the prefix only appears in docstrings.

Apply patch_96_97_{c,d,e}, insert the necessary data into
homo_sapiens/core.

Quote noisy strings properly + avoid double-sigil dereferences.

Doesn't really matter since this xref was processed entirely offline -
but just in case.

The type in this case is expressed using human-readable code, which is
then translated to numerical ID using data from the rnaproduct_type
table.

More useful, for instance for the upcoming implementation of
Transcript::get_all_RNAProducts() with type filtering. Drawback: must do
a join between rnaproduct and rnaproduct_type on all queries so that
RNAProductAdaptor has got something to put in this field.

Complete with relevant updates to RNAProductTypeMapper and its tests.

There is now a dedicated class, Utils::RNAProductTypeMapper, which
provides type_id<->class_name mappings to both RNAProduct constructor
(with the side bonus of no longer having to set the type ID in the
constructor of each subclass) and RNAProductAdaptor. The latter will
likely be used more frequently than the former, therefore the default
map uses type IDs as keys; the reverse map is only generated the first
time it is needed.

In addition to the constructor, the RNAProductTypeMapper.pm defines a
function called mapper() which provides a singleton instance of the
mapper object.

The mappings are hardcoded instead of being retrieved from the database
because the latter could in principle result in execution of arbitrary
code.

Some tests have been defined as well.

The optional argument allows the user to only retrieve RNA products of
specific type, e.g. microRNAs. At the moment the type has to be
specified by a numerical ID, in the future this will be changed to allow
the passing of string codes.