Feat/liftover existing variants - #601
Conversation
This code can be used to perform lift overs automatically whenever a certain variant description is left empty for a certain build.
This commit adds the code that performs the lift over, checks the output and sends it to the database. Also, it contains new code that outlines the approach to add flags to the variant to specify the mapping status.
Instead of using isset(), set them to false at the start and simply check if they were set to true in the end.
This commit makes sure that, if VV returned multiple VOG descriptions for one GB, they are now cleanly concatenated to one descriptions. Also, this commit ensures that, if no positions could be retrieved for a certain variant, their positions are set to 0.
| // Great! All checks have passed. Now all that is left to do is to | ||
| // ensure the variants are correctly concatenated in case multiple | ||
| // descriptions were found on the build in question. | ||
| if (is_string($aVVResponse['data'][$sBuild])) { |
There was a problem hiding this comment.
This whole thing (line 315-338) is also performed in ajax/check_hgvs_dialogue.php in the branch improve/variantCreationForm. Perhaps we could unify the code by building a function for both cases?
There was a problem hiding this comment.
In that case, that should then be in the VV library. I'm not really sure yet if maybe this entire problem should be solved inside of the VV library instead of outside of it.
There was a problem hiding this comment.
I think it would be nice to do so inside the library!
We actually do not want to add MAPPING_DONE after finishing a lift over, since this also affects the mapping of transcripts. So, we keep that. Also, we no longer remove MAPPING_IN_PROGRESS after finishing, since this is redundant because of the exit function of map_variants.php that ensures this removal already.
ifokkema
left a comment
ifokkema
left a comment
There was a problem hiding this comment.
I realized too late you were still working on this - here are some comments already!
| // Great! All checks have passed. Now all that is left to do is to | ||
| // ensure the variants are correctly concatenated in case multiple | ||
| // descriptions were found on the build in question. | ||
| if (is_string($aVVResponse['data'][$sBuild])) { |
There was a problem hiding this comment.
In that case, that should then be in the VV library. I'm not really sure yet if maybe this entire problem should be solved inside of the VV library instead of outside of it.
The MAPPING_ALLOWED flag only indicated whether mapping was allowed between VOG and VOT, so for the liftovers (VOG to VOG), this is not relevant. So this requirement should be removed and is so by this commit!
GVI = lovd_getVariantInfo()
The $_DB->query() function places quotes around integer variables in SQL queries to quicken searches. However, SQL's LIMIT function only accepts integers, so these variables should not be sent in between quotes and should therefore be given directly, so without using a placeholder.
The GVI warning 'WTRANSCRIPTFOUND' does not make the variant non-HGVS- compliant, so this warning should be allowed. Also: the 'supported_by_VV' flag is not yet available in this branch, so it cannot be used to find out whether a variant is supported by VV. This should be added in the future as soon as the relevant code has been pulled in.
To check whether all variants are described on all builds, we first want to check whether each specific build holds empty descriptions. First, we did this for all builds at once in a loop. This made it difficult to ensure that a certain maximum of variants would be filled at a time. Now that we have randomised the GBs, it is better to simply take the first GB and only map the others after a new call to the script has been made.
|
The code currently seems to work as I want it to. There is one problem still: the --> Update 09/06: I have fixed the mapping_in_progress problem with the latest commit! The code has been tested quite extensively and, to me, is no longer a draft. |
The $aVariantUpdates variable is used to store variants that are currently in progress and ensure that the in_progress mapping flag is removed when the progress is finished. Before, this variable was not filled correctly; now it is.
2 participants
This code will identify existing variants that are not described on all active GBs, and add missing descriptions wherever possible by performing lift overs using VariantValidator.
Closes #600, related to #550.