Metagenotype changes should propagate to annotation extensions

[jseager7]

(Requested by @CuzickA)

We've noticed that once a metagenotype is used in our compared_to_control annotation extension (which has MetagenotypeID as its range), the extension value doesn't update if the metagenotype it references is changed. This means the curator has to recreate all of the annotation extensions manually (sometimes upwards of 20 at a time).

@kimrutherford Am I right in thinking that the annotation extension merely sets its value to a copy of the display name of the metagenotype? If so, how difficult would it be (for me) to change the extension so that it references the current version of the metagenotype? I doubt this has ever been a problem before, because the only other feature that's used as a range ID is GeneID, and that's immutable in a curation session.

Another option could be to add a feature for bulk-editing annotation extension range values across multiple annotations, but that could be even more complicated than the other fix.

[kimrutherford]

Am I right in thinking that the annotation extension merely sets its value to a copy of the display name of the metagenotype?

It stores the metagenome database ID and the display name. If the metagenotype changes the display name stored in the extension isn't updated. The current implementation isn't great. In the database the extension should probably just contain the ID and the Perl code should fill in the name before returning the JSON to Javascript code. I'll have a look at doing that.

[ValWood]

This is similar to needing to edit "multi-gene genotypes" when one of the contributing genotype changes. I thought there was a ticket about this, but I can't find it.

[mah11]

This is similar to needing to edit multi-genelocus genotypes when one of the contributing genotype allele names or descriptions changes. I thought there was a ticket about this, but I can't find it.

The main one is #2304 (and it links to #1901, but that one has less detail).

[mah11]

corrected ticket link (#2304) ...doh

[jseager7]

@kimrutherford This problem keeps showing up now that we have new curators on the project. Could you please take another look at this when you have time? I'm happy to help test or make changes.

[kimrutherford]

Just to be clear, what sort of metagenotype changes are we talking about? Can metagenotypes change after creation?

[jseager7]

Can metagenotypes change after creation?

Kind of. It's more the fact that the underlying genotypes can be edited, and because they're only referenced by the metagenotypes (not copied), the changes should propagate to the display names. Metagenotypes themselves are technically immutable in PHI-Canto.

For example, when the display text for a wild type expression level of a gene product was changed from 'WT product' to 'WT level' everywhere in Canto, the change wasn't reflected in the metagenotype display names, only the genotype display names when they were displayed in isolation.

[jseager7]

If the genotype display names are always updated correctly, perhaps it's easy for PHI-Canto to just concatenate the genotype display names to form the metagenotype display name at runtime, like you suggested.

An ideal fix would be recalculating relevant metagenotype display names only when their constituent genotypes are updated (then caching the display names for later), though if this can't be enforced by some constraint in the database then it could be a bit flaky.

[kimrutherford]

perhaps it's easy for PHI-Canto to just concatenate the genotype display names to form the metagenotype display name at runtime

I haven't investigated that plan yet. Sorry! My current excuse is that I have Covid. I've put it at the top of my to-do list for when my brain is not so fuzzy.

[jseager7]

@kimrutherford No worries. We can already work around this issue manually anyway, so it's not urgent (despite the label). If I get any spare time I'll try to take a look at the code myself. Get well soon!

[kimrutherford]

The current implementation isn't great. In the database the extension should probably just contain the ID and the Perl code should fill in the name before returning the JSON to Javascript code.

I've made a PR that implements a first pass at this: #2557

@jseager7 would you be able to try out the change when you have a chance?

Currently there is no caching of the metagenotype display name - it's calculated as needed. This may be too slow for large sessions. If so, we'll need to do some more work.

On Monday I'll investigate how this change interacts with exporting Canto sessions to JSON. That code might need changes too.

[kimrutherford]

On Monday I'll investigate how this change interacts with exporting Canto sessions to JSON. That code might need changes too.

It's all fine as far as I can see. No changes needed.

[jseager7]

Fixed by #2557. The metagenotype display names are now calculated as needed in the interface and when exported as JSON.