-
Notifications
You must be signed in to change notification settings - Fork 1
Application Logic
A record's parents are any sibling records in the same model that have been semantically associated to the record via the use of either or both the part_of or from_prototype foreign key attributes. A record's parents also include the parents of such sibling records and their parents' parents, and so on, via use of the same logic.
The purpose of tracking parents is to maintain somewhat an OOP type hierarchy of model records. The application logic has been written such that the application views will display the values of the parents' attribute for a particular foreign key in addition to the values of the record's own foreign key attribute, but on a case-by-case basis (only when it makes sense to do so).
For example, imagine a Biosample record with two documents (say that are grow protocols) associated to it. At some point in time, a user clones the Biosample via the "clone" button on the Biosample show view in order to represent an aliquot being taken from the Biosample. The Biosample model has a clone method that knows how to clone a Biosample record - copying only the relevant attributes to the new record and also setting the part_of association attribute of the new record to point to the Biosample record from which it was cloned. This is what establishes a parental relationship for the part_of side of things. Not all models have or even need to be cloned, thus only certain ones have the part_of attribute (likewise for the from_prototype attribute that is explained later). Now, when the user visits the home page of the cloned Biosample, it will show the same two documents that are from the parent Biosample, yet, the clone isn't directly linked to them.
The main purpose of cloning and keeping track of parents is so that the user doesn't have to manually make and maintain a group of nearly identical records that could be quite tedious to do. If the user wanted say 10 Biosample records to look the same except for their name (again maybe 10 aliquots were taken from a particular Biosample record), maybe because they will each undergo the same experiment in replicate, then the cloning feature comes in quite handy. The parental tracking mechanism comes in handy when an udpate needs to happen to all cloned Biosamples (or any other model type that supports cloning, such as the Library or Crispr Modification). Extending our example, if the user realized that all 10 cloned Biosamples should have a Document added or removed, then all the user needs to do is update the parental Biosample used initially for cloning.
This is especially useful in the case of SingleCellSorting (SSC) experiments. Each time the user adds a new Plate record on a SSC experiment, a Biosample needs to be created for each Well of the Plate, and later on a Library for each Biosample. Since a SSC can have multiple Plates, and each Plate can have upto 96 Wells, this LIMS would quickly be abandoned if it forced the user to create Biosamples and Libraries for each well manually. Instead, the application uses record cloning behind the scenes. The user first must select what is called a starting biosample, which represents in the real world the biosample material that goes into the sorting machine. The user is also required to fill out the details for what is called a sorting biosample to indicate what is being sorted into each well of a plate (which is in turn modeled as a Biosample record). Then, when the user models a sorting event into a 96 well plate by adding a new Plate record, the sorting biosample is cloned 96 times behind the scenes. Each clone has the from_prototype attribute set to point to the sorting biosample record. Whenever the user needs to update something across all 96 biosamples, the user just needs to update a single record - the sorting biosample. Why not instead use the part_of attribute instead of from_prototype on each Biosample clone? Because the sorting biosample isn't an actual biosample in the real world - it's really just a blueprint for a Biosample record and is thus called a prototype. Instead, each clone's part_of attribute is set to the starting biosample.