Closed cmgrulke closed 3 years ago
@cmgrulke The name SourceSubstance seems like a confusing name for this model. The name current feels like it implies a connection between source (#89) and substance (#90).
You also explained previously you had the "mapping" fields as a separate one-to-one model. I don't see a reason this needs to be a one to one relationship as the logic, as I understand it, that a "Record" would be connected to an accepted and curated "Substance". This functionality is similar to how chemical records from data sources (RawChems) in Factotum map to DSSToxLookups.
rid = a varchar id minted similarly to the DTXSID and DTXCID, but starting with DTXRID
external_id = String (Less than 500 characters, required field)
list = Foreign key to list (one to many)
substance = Foreign Key to substance (one to many) (optional)
score = Float (optional)
message = String (Less than 500 characters, optional)
is_validated = boolean (required)
Yup, I am good with both 1 and 2
As a product owner I want to be able to store all the identifiers associated with a member of a source list So that I can use those identifiers both to resolve the source_substance to a substance and potentially to link to an external resource
A Source Substance (Record) Consists of the following fields: record_id = a varchar id minted similarly to the DTXSID and DTXCID, but starting with DTXRID external_id = String (Less than 500 characters, required field) Mapped Substance = A substance (issue #90) (optional) Mapping score = Float (optional) Mapping message = String (Less than 500 characters, optional) Mapping is_validated = boolean A List = the list this is a member of (issue #174) (required)
Acceptance Criteria A test to show when a source substance is created it works properly...