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.

Sign up for GitHub

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

Jump to bottom

patch existing observations for project 118 and 160 #580

Merged
merged 3 commits into from
Sep 9, 2024
Merged

patch existing observations for project 118 and 160 #580

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
92785c4
patch existing observations for project 118 and 160
ayobi Aug 28, 2024
7e75e08
update query if project id exists
ayobi Aug 29, 2024
179fb53
remove left join
ayobi Sep 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions microsetta_private_api/db/patches/0142.sql
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
-- August 26, 2024
-- Patching 0141 Sample Observation Project Association
-- to add projects 118 and 160.

WITH all_observations AS (
SELECT observation_id FROM barcodes.sample_observations
)
INSERT INTO barcodes.sample_observation_project_associations (observation_id, project_id)
SELECT observation_id, project_id
FROM all_observations
CROSS JOIN (VALUES (118), (160)) AS new_projects(project_id);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why only these two projects?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wasade Per Se Jin, those are the only two projects we anticipate processing fecal samples for in the near future. Sample observations will be associated with other projects on an as-needed/as-appropriate basis.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but the sample_observations table doesn't exist on production so there are no observations. And, it looks like there is no guarantee that project_id is correctly associated to the sample (see

microsetta-private-api/microsetta_private_api/db/patches/0141.sql

Lines 23 to 24 in 233e89c

observation_id UUID NOT NULL,
project_id INT NOT NULL,
) as that information is housed in the project_barcode table. That could lead to a scenario where there are two "truths"

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, but the sample_observations table doesn't exist on production so there are no observations.

I haven't done a deploy since we added sample_observations.

That could lead to a scenario where there are two "truths"

Are you referring to the fact that a barcode can belong to multiple projects, and could therefore be associated with zero, one, or two-plus projects for which we have associated sample observations? If so, we took the view that, if a barcode is associated with at least one project for which we have associated sample observations, those observations will be available to note at the time of scanning in the wet lab.

If that's not what you're referring to, then I'm unclear on the second point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But doesn't that mean there are no observations (i.e., SELECT observation_id FROM barcodes.sample_observations is the empty set), therefore the patch isn't necessary?

For multiple truths: our ground truth for barcode <-> project association is the project_barcode table, which relates a barcode to a project. The sample_observation_project_associations allows for associating an observation_id with a project_id without an enforced constraint that the implicitly associated barcode is associated to the project. Does that make sense?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But doesn't that mean there are no observations (i.e., SELECT observation_id FROM barcodes.sample_observations is the empty set), therefore the patch isn't necessary?

Patch 141 inserts values into the barcodes.sample_observations table and associates them with project ID 1 via the barcodes.sample_observation_project_associations table. This patch (142 at the time I'm writing this) uses the same records in barcodes.sample_observations that patch 141 created and associates them with more project IDs.

For multiple truths: our ground truth for barcode <-> project association is the project_barcode table, which relates a barcode to a project. The sample_observation_project_associations allows for associating an observation_id with a project_id without an enforced constraint that the implicitly associated barcode is associated to the project. Does that make sense?

It makes sense in a technical sense but I'm unclear on why it's relevant to this patch. The barcodes.sample_observation_project_associations doesn't associate anything with barcodes, nor does it intend to. It makes a set of observations available on the Scan Barcode page when a barcode associated with one of those project is scanned. If the sample being scanned meets one of the observations, the wet lab tech will then select it as a means of recording notable aspects of a given sample so that, in the future, we can refine both wet lab SOPs and the online tools that are used to handle sample ingestion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I see now, thanks!

Loading