Store sample storage location information as well as the hierarchical structure information.
This class performs two functions. The reasoning will be explained below.
First, this class stores the location information, identified by the name and index fields. For
example, a 96 well plate numbered 42 may have name="Plate" and index="42". The plate may have
children, say 96 of them. This class does not restrict the number of children, but a controller
may look at this class's
SampleType field and determine the minimum and maximum number
of children this storage unit can have.
The children of Plate-42 will be 96 wells, with name="Well" and index numbered from "A1" to
"H12". When a
Sample is associated with a location,
it may in this case point to the
Storage object Well-A1. In turn, Well-A1 is held in Plate-42. Conveniently, the name and index
can be concatenated to give the user a friendly name, such as Plate-42 and Well-A1.
There is not a limit on the amount of hierarchy a Storage object can have. For example, Freezer-1
can hold Shelf-2 which holds Rack-3 which holds Plate-42 which holds Well-A1. In a large freezer,
there maybe many Well-A1s, but they all have unique ids (UUIDs) and different parents. The
associations can be freely moved around by changing the parent field. For example, Plate-42 maybe
moved to Rack-1 from Rack-3, and the children wells would not notice.
Furthermore, there is no limitation on what can be a child of a parent. In a real freezer,
Shelf-2 may contain Rack-3 and also a paper box with 81 slots (Call them Box-5, wth Slot-1 to
Slot-81), with a tube in each slot (Tube-1138). In this case, a Sample object would be associated
with Tube-1138, as that is the object that can be moved between slots or boxes.
Most laboratories have a fixed types of containers, or some scheme of organization. So it would
be useful to store some information about the scheme of hierarchy such as
Freezer->Shelf->Rack->Plate->Well or Freezer->Shelf->Box->Slot->Tube. Additionally, different
entry types may require different storage schemes. For example, plasmids can be stored in tubes
or in plates, and seeds can be stored in tubes or boxes.
Therefore, what is needed is also a class for storage schemes with its own parent/child
relationships. For example, Plasmid storage scheme can have two child storage schemes, one for
plates and other for tubes. But the difficulty lies in that each storage object can have multiple
child storage schemes. For example, the shelf of a freezer can contain both racks and boxes, with
separate storage schemes. So we work around this by inserting the storage schemes directly into
the storage object instead of creating a separate class. Furthermore, if the storage scheme
changes, for example insertion or deletion of layers, this does not adversely affect already
existing storage hierarchies.
There are other advantages of storing the scheme information directly into the Storage object.
And then there are disadvantages. Advantages seem to outweigh the disadvantages in this
application.
TODO.