Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Postgresql error for isolate_name dose not match what actually happened #29

Open
KaimingTao opened this issue Jan 27, 2022 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@KaimingTao
Copy link
Member

Paper: Boschi22
Isolate name: hCoV-19/France/PAC-IHUMI-2096/2020
Variant name: B.1.160

The paper is about mAbs, not plasmas, but the error prompt is about the subject history of plasmas.

Screenshot
Screen Shot 2022-01-26 at 18 15 48

Currently, these records are excluded from the database.

@KaimingTao KaimingTao added the bug Something isn't working label Jan 27, 2022
@philiptzou
Copy link
Member

philiptzou commented Jan 27, 2022

This is not a bug. It's a validation I added to forbid using B.1.160 (477N+614G) as the var_name of an isolate which is linked to at least one susceptibility test result. Leave the var_name "NULL" can solve this problem.

@KaimingTao
Copy link
Member Author

This is not a bug. It's a validation I added to forbid using B.1.160 (477N+614G) as the var_name of an isolate which is linked to at least one susceptibility test result. Leave the var_name "NULL" can solve this problem.

Sorry I didn't get the context. Why B.1.160 can't be used for an isolate, and the isolate is used in the susc_result table?

Also, the issue is not about the var_name. The prompt mentioned subject_history table, but the B.1.160 used in Boschi22 is only about monoclonal antibodies.

@philiptzou
Copy link
Member

philiptzou commented Jan 29, 2022

@KaimingTao It's the same reason why we don't assign D.2 to an isolate. You can find the detailed reason by searching for and read the email thread "Why is S477N mutation listed on the dashboard as D2 (S477N)". You can only use B.1.160 and D.2 in subject_history.

Basically, D.2 and B.1.160 only includes two Spike mutations S477N+D614G. We decided to aggregate the neutralization result of D.2 and B.1.160 by their mutation pattern but not by their variant so the results can be merged with S477N. However, if you specify a variant to the isolate, the neutralization result will be aggregated by its variant but not by its mutation pattern.

You can still specify B.1.160 or D.2 to an isolate used as infected virus. Since 1) #11 will eventually change infected_isolate to infected_variant in the proposed subject_infections table; 2) infected viruses don't use the same complicated aggregation rule used by control and test isolates - they always aggregated by their variants.

@philiptzou philiptzou transferred this issue from hivdb/covid-drdb-payload Feb 10, 2022
@philiptzou
Copy link
Member

This issue is moved to covid-drdb since it's related to this constraint:

DO $$
DECLARE row isolates%rowtype;
BEGIN
FOR row IN SELECT * FROM isolates iso WHERE
var_name IN ('B.1.177.75', 'B.1.160', 'D.2') AND (
EXISTS (
SELECT 1 FROM rx_potency pot WHERE
pot.iso_name=iso.iso_name
) OR
EXISTS (
SELECT 1 FROM rx_fold f WHERE
f.control_iso_name=iso.iso_name OR
f.iso_name=iso.iso_name
)
)
LOOP
RAISE EXCEPTION E'Isolate of variant \x1b[1m%\x1b[0m can be only used as an infected isolate in subject_history. Unlink \x1b[1m%\x1b[0m from \x1b[1m%\x1b[0m to be used in rx_potency or rx_fold.', row.var_name, row.iso_name, row.var_name;
END LOOP;
END
$$;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants