patch existing observations for project 118 and 160 #580
Conversation
| 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); |
There was a problem hiding this comment.
@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.
There was a problem hiding this comment.
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
project_barcode table. That could lead to a scenario where there are two "truths"
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
This patch associates all of the existing observations with projects 118 and 160.