From 5d421a4a3ad65e8ff7598d79ae34854b378611b4 Mon Sep 17 00:00:00 2001 From: Marina Gourtovaia Date: Wed, 28 Aug 2024 16:21:07 +0100 Subject: [PATCH 1/2] Explained QC outcome change for complex products --- docs/qc_outcomes_change_howto.md | 35 ++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/docs/qc_outcomes_change_howto.md b/docs/qc_outcomes_change_howto.md index b7a8b245..ed142198 100644 --- a/docs/qc_outcomes_change_howto.md +++ b/docs/qc_outcomes_change_howto.md @@ -5,6 +5,41 @@ - Wrap database changes into a transaction, which initially should have a clause to fail it so that it can be tried out (see some examples below). +All listed below procedures were originally written for products containing +one component. Procedures for changing the already existing QC outcomes should +also work for products containing multiple components as long as these +components are from the same run and are for the same tag index. Use any lane +number (position) that went into the merged product. For example, for a product +described by JSON below + +``` +{ + "__CLASS__": "npg_tracking::glossary::composition-101.3.0", + "components": [ + { + "__CLASS__": "npg_tracking::glossary::composition::component::illumina-101.3.0", + "id_run": 49404, + "position": 7, + "tag_index": 1 + }, + { + "__CLASS__": "npg_tracking::glossary::composition::component::illumina-101.3.0", + "id_run": 49404, + "position": 8, + "tag_index": 1 + } + ] +} +``` + +use the following expression for a search when toggling the QC outcome + +``` +my $rs=npg_qc::Schema->connect()->resultset("MqcLibraryOutcomeEnt") + ->search_autoqc({id_run=>49494,position=>7,tag_index=>1}); +``` + + ## Toggle the outcome of a single library QC outcome will change from `pass` to `fail` or `fail` to `pass`. From 37330d1d3dc4fef644c749826daf47737c2f81dd Mon Sep 17 00:00:00 2001 From: Marina Gourtovaia Date: Thu, 29 Aug 2024 10:52:27 +0100 Subject: [PATCH 2/2] Post-review text improvements --- docs/qc_outcomes_change_howto.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/docs/qc_outcomes_change_howto.md b/docs/qc_outcomes_change_howto.md index ed142198..8c474dda 100644 --- a/docs/qc_outcomes_change_howto.md +++ b/docs/qc_outcomes_change_howto.md @@ -6,13 +6,13 @@ a clause to fail it so that it can be tried out (see some examples below). All listed below procedures were originally written for products containing -one component. Procedures for changing the already existing QC outcomes should -also work for products containing multiple components as long as these +one component. Existing procedures for changing the already existing QC outcomes +should also work for products containing multiple components as long as these components are from the same run and are for the same tag index. Use any lane number (position) that went into the merged product. For example, for a product described by JSON below -``` +```json { "__CLASS__": "npg_tracking::glossary::composition-101.3.0", "components": [ @@ -39,6 +39,13 @@ my $rs=npg_qc::Schema->connect()->resultset("MqcLibraryOutcomeEnt") ->search_autoqc({id_run=>49494,position=>7,tag_index=>1}); ``` +The custom `search_autoqc` method returns a resultset containing QC outcomes for +products which contain a component with position 7 and tag_index 1, which will +be the merged product described by the above JSON. If the QC database records +are correct, the resultset should contain one row. The same resultset is +returned if 8 is used as the value of the position. There should not be any need +to repeat the process for every position that went into the merge and in a case +of a toggle this would be wrong. ## Toggle the outcome of a single library