Skip to content

Capture max_vol_per_well from GUI and store in DB somewhere #454

@AmandaBirmingham

Description

@AmandaBirmingham

Related to #438 .

Rodolfo has said that he is ok with hard-coding the max_vol_per_well value to 20 µL for the shotgun pooling (echo picklist creation). However, this makes me distinctly nervous: the lab has changed the max_vol_per_well value in the past (e.g., "We changed it from 60µL to a lower 20-30 µL because we changed destination plates and the newer plates hold less volume") which I suspect means changes like this could happen again when something else like new plates comes up.

Also, with the max_vol_per_well value hardcoded in the python code, we have NO RECORD in the DB of what volume was actually used for pooling. If (when? :) ) the lab decides to change this value, we will not have any way to tell which past pools were pooled with the old value and which were pooled with the new value.

This also relates to #417 : "re-downloading" the echo picklist is really regenerating it from scratch, which means that if you went to "redownload" a picklist after the max_vol_per_well had changed, you would get a different picklist than the one you originally had. Maybe this is what you'd want or maybe it isn't (depending on whether you were re-downloading it to do a new pooling or to check the details of what you did in the past!)

Someday--at the very least, when the lab next decides they want to change that volume--the shotgun pooling interface should be extended to capture the max_vol_per_well from the user rather than hard-coding it, AND the labman.pooling_process table should be extended to store this info.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions