Ensure that data duplication by "contents" field in sample_composition is acceptable

[AmandaBirmingham]

This commit josenavas@b9053ec added a new field to the sample_composition table called "content" (this field name really could use some work ...). It is a fix for issue #34 . This new field contains one of two values, depending on whether the sample_composition record represents an experimental sample or not. If it is an experimental sample, the "content" field contains a concatenation of the sample_id column value plus underscore plus the plate id of the plate that the well containing this sample is on plus underscore plus the well id (A1, etc) of the well containing this sample. If, on the other hand, the sample_composition is for something other than an experimental sample (like a control, an empty, etc), then the content field contains a concatenation of the sample_composition_type.external_id for the sample_composition_type field value for this record, plus underscore plus the plate id of the plate that the well containing this sample is on plus underscore plus the well id (A1, etc) of the well containing this sample.

The red flag about this is that it duplicates the information about a sample composition's plate and well location. In the original design of the database, that information was available ONLY by going from sample_composition.composition_id to composition.container_id to the well.container_id with that container_id, from which one could get the row, column, and plate of the well. But now that info also exists encoded in a string in the sample_composition.content, and having info in two places means that those two representations COULD get out of sync with each other. It also encourages users of the db to be lazy and get the plate and well info by parsing the "content" string, rather than following the intended (and foreign-key-enforced) join path to get the information from where it is supposed to live.

That said, as far as I can tell it, this duplication doesn't actually break any expected use-cases for the db, because each composition is supposed to belong to only one container (e.g., well), so it should be the case that the content (including well and plate id) can be unchanging.

[charles-cowart]

Let's make a decision about whether this is acceptable before full launch; post launch schema changes and migrating data would be preferable to avoid.

[charles-cowart]

@AmandaBirmingham @wasade No movement on this in 8 days - would it be better to debate it here or have a meeting over it?

[charles-cowart]

Making it a high priority, at least w/respect to making a decision.