Update to support new DB structure with multiple pockets. - #851
Conversation
| $self->{config}->{output_format} eq "vcf" | ||
| ? "(fields are separated by '&') " | ||
| : "(fields are separated by ',') "; | ||
| $header{ProtVar_pocket} = "Information about overlapping protein pocket. Output records are separated by '&'; field(s) include: "; |
There was a problem hiding this comment.
Hi @jamie-m-a , Looks good. 👍
For other output format the delimiter is , but for VCF it is &. So we need to update the header description here.
Also Needs to properly use delimiter in the output,
for VCF two pocket output are delimited by & as well as the fields for those pocket output, so we cannot separate two pockets -
P4&897.4969555629044&83.33136363636362&0.362285&0.789264&7.645393&p111p112p113p114p115p116p117p118p119p120p121p124p149p150p151p152p153p156p313p316p317p320&P12&515.7658017356196&87.736875&0.330738&0.747748&4.331085&p114p115p117p118p119p120p123p316p319p320p321p322p323p324p330p343
There was a problem hiding this comment.
Agreed - simplest was to follow standard field arrangement, so reverted to that.
| my $key = "ProtVar_" . $item; | ||
| my @formatted_records; | ||
| my $field_delimiter = $self->{config}->{output_format} eq "vcf" ? "&" : ","; | ||
| my $record_delimiter = "|"; |
There was a problem hiding this comment.
record delimiter in vcf would not work here as it is already used as separator between CSQ field , e.g. -
G|missense_variant|MODERATE|...
phenotype with similar output format uses + as field delimiter and & as record delimiter. We can re-use same logic?
nakib103
left a comment
There was a problem hiding this comment.
LGTM, thanks @jamie-m-a
|
merged to |
ProtvarDB generation had a slight issue, it wouldn't store more than one protein pocket per variant (over wrote if there were more than one).
A new generation script was made to create the new DB structure (and run faster by downloading all required data then caching in memory). Runs in ~25 mins versus days. New script and new DB in:
Updated plugin works on old and new DBs - backward compatible.
Files are in
/nfs/production/flicek/ensembl/variation/data/ProtVarcreate_uniprot_id_list.pl(script to generate all require uniprot IDs)prepare_data.pl(script to generate new SQL DB)ProtVar_data_UPDATE.db(generated DB)The following variant demonstrates the difference:
11 19237425 . T GLooking at the
ProtVar_pocketfield output.Pointing at old DB
/nfs/production/flicek/ensembl/variation/data/ProtVar/data/ProtVar_data.db→
P12&515.7658017356196&87.736875&0.330738&0.747748&4.331085&p114p115p117p118p119p120p123p316p319p320p321p322p323p324p330p343Just P12 pocket
Pointing at new DB
/nfs/production/flicek/ensembl/variation/data/ProtVar/ProtVar_data_UPDATE.db→
P4&897.4969555629044&83.33136363636362&0.362285&0.789264&7.645393&p111p112p113p114p115p116p117p118p119p120p121p124p149p150p151p152p153p156p313p316p317p320&P12&515.7658017356196&87.736875&0.330738&0.747748&4.331085&p114p115p117p118p119p120p123p316p319p320p321p322p323p324p330p343Now both a P4 and P12 pocket
Verifying on ProtVar