Case-attributes metadata for samples. They are include: sex, age, etc of the various individuals and exist separately from "normal" traits mainly because they're non-numeric. From the GN2 traits page, they are shown as extra columns under the "Reviews and Edit Data" section.
Case-attributes are determined at the group-level. E.g. for BXD, case attributes would apply at the level of each sample, across all BXD data. Every strain has a unique attribute and it's fixed, not variable.
We need to differentiate these two things:
Currently, both labels and values are set at the group level:
is a good starting point to help with understanding how case-attributes were implemented and how they worked.
Critical bug existed where editing one case-attribute affected all case-attributes defined for a group.
Case attributes can have the following data-types:
Example SQL query to fetch case-attribute data:
SELECT caxrn.*, ca.Name AS CaseAttributeName, ca.Description AS CaseAttributeDescription, iset.InbredSetId AS OrigInbredSetId FROM CaseAttribute AS ca INNER JOIN CaseAttributeXRefNew AS caxrn ON ca.Id=caxrn.CaseAttributeId INNER JOIN StrainXRef AS sxr ON caxrn.StrainId=sxr.StrainId INNER JOIN InbredSet AS iset ON sxr.InbredSetId=iset.InbredSetId WHERE caxrn.value != 'x' AND caxrn.value IS NOT NULL;
CaseAttributeXRefNew differs from CaseAttributeXRef:
mysql> describe CaseAttributeXRef; +------------------+----------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +------------------+----------------------+------+-----+---------+-------+ | ProbeSetFreezeId | smallint(5) unsigned | NO | PRI | 0 | | | StrainId | smallint(5) unsigned | NO | PRI | 0 | | | CaseAttributeId | smallint(5) | NO | PRI | 0 | | | Value | varchar(100) | NO | | | | +------------------+----------------------+------+-----+---------+-------+ 4 rows in set (0.01 sec) mysql> describe CaseAttributeXRefNew; +-----------------+------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------+------------------+------+-----+---------+-------+ | InbredSetId | int(5) unsigned | NO | PRI | NULL | | | StrainId | int(20) unsigned | NO | PRI | NULL | | | CaseAttributeId | int(5) unsigned | NO | PRI | NULL | | | Value | varchar(100) | NO | | NULL | | +-----------------+------------------+------+-----+---------+-------+ 4 rows in set (0.01 sec)
Possible set of privileges subject to discussion:
Given groups are not directly linked to any auth resource, we may introduce some level of indirection. Addy a new resource type that handles groups may solve this.