Details
Now that we have WellVolumeAdjustment in our data model, we can consider
implementing the following data model simplifications:
- replace CopyInfo.microliterWellVolume with a positive-valued
WellVolumeAdjustment. In this way, we could calculate the remaining
volume of a well without inspecting CopyInfo.microliterWellVolume. We'd
just sum up the positive- and negative-valued WellVolumeAdjustments for
a well. One other minor benefit is that each of these
"initialization"
WellVolumeAdjustments could be tied to an AdministrativeActivity record
that would show who/when updated the database with the initial well
volumes.
- When a CherryPickAssayPlate is marked as "failed", a new CPAP is
created for the next creation attempt, and all of the LabCherryPicks
from the failed plate are duplicated for the new plate. This duplication
was necessary when LabCherryPicks were the means by which well volume
depletions were tracked. Now that we have LCP.wellVolumeAdjustments in
the model, we can probably dispense with duplicating LabCherryPicks when
a plate fails. And in fact, we can probably even dispense with creating
a new CherryPickAssayPlate for each plate creation "attempt" of a
given
plate number (the name CherryPickAssayPlate is a bit misleading, since
it signifies an *attempt*, and there can be > 1 per "logical"
assay
plate). We could stick track the failed attempts of a CPAP by making
CPAP.cherryPickLiquidTransfer into a *set* of
CPAP.cherryPickLiquidTransfers. So really, this is just an exercise in
re-normalization. Lots of code simplifications would result.
We could have addressed these improvements in #79216, but wanted to keep
changes as simple as possible in our ongoing effort to resolve #79213. |
Details
Now that we have WellVolumeAdjustment in our data model, we can consider
implementing the following data model simplifications:
- replace CopyInfo.microliterWellVolume with a positive-valued
WellVolumeAdjustment. In this way, we could calculate the remaining
volume of a well without inspecting CopyInfo.microliterWellVolume. We'd
just sum up the positive- and negative-valued WellVolumeAdjustments for
a well. One other minor benefit is that each of these
"initialization"
WellVolumeAdjustments could be tied to an AdministrativeActivity record
that would show who/when updated the database with the initial well
volumes.
- When a CherryPickAssayPlate is marked as "failed", a new CPAP is
created for the next creation attempt, and all of the LabCherryPicks
from the failed plate are duplicated for the new plate. This duplication
was necessary when LabCherryPicks were the means by which well volume
depletions were tracked. Now that we have LCP.wellVolumeAdjustments in
the model, we can probably dispense with duplicating LabCherryPicks when
a plate fails. And in fact, we can probably even dispense with creating
a new CherryPickAssayPlate for each plate creation "attempt" of a
given
plate number (the name CherryPickAssayPlate is a bit misleading, since
it signifies an *attempt*, and there can be > 1 per "logical"
assay
plate). We could stick track the failed attempts of a CPAP by making
CPAP.cherryPickLiquidTransfer into a *set* of
CPAP.cherryPickLiquidTransfers. So really, this is just an exercise in
re-normalization. Lots of code simplifications would result.
We could have addressed these improvements in #79216, but wanted to keep
changes as simple as possible in our ongoing effort to resolve #79213. |