Open scharch opened 3 months ago
From the call:
members
and inferred_members
down to a single revived but skinny Node
arrayNode
should have both sequence_id
and cell_id
with only one populated (but maybe add a level
shortcut too?)Cell.inferred
and Rearrangement.inferred
to an enum to match Repertoire.type
and add this to Node
as well
Node
need to be part of a Repertoire
at all? Maybe this allows us to drop that bit entirely...repertoire_id
to Node
to facilitate retrieval of underlying datadata_processing_id
Random thoughts:
repertoire_type
what about observed
instead of physical
?inferred
boolean for Rearrangement could instead be sequence_type
and use the same enum as repertoire_type
? Same for Cell
and a cell_type
field.level
/members
in Clone
, we could have sequences
/ cells
which are explicitly typed and set the expectation to only populate one (we could still retain level
in this case).level
/members
in Clone
would be to have a different version of Node
that contains the sequence_id
/cell_id
fields (without the junction and whatnot), and possibly the level
/sequence_type
/cell_type
, and possibly the repertoire_id
so that doesn't need to be fetched out of RepertoireGroup
somehow. Ie, members
contains Node
references.
- [ ] What do we do about
data_processing_id
? CanRepertoireGroup
s get their ownDataProcessing
objects?
@scharch It's best to think of DataProcessing
as an independent, orthogonal object to the other (top-level) AIRR objects. Anything that can be part of DataProcessing
should have a data_processing_id
so yes including one in RepertoireGroup
makes sense.
OK, let me know how this looks.
rearrangement_type
and cell_type
enums instead of inferred
booleansNode
as a way get repertoire_id
in. It feels a little "overweight" but probably the best solution?
Draft of updates to
Clone
. Closes:201 (incidentally)
317
333
378
769
Open questions, both related to the switch from
Repertoire
toRepertoireGroup
:_id
s inmembers
(etc)? Currently, one would have to search eachRepertoire
in theRepertoireGroup
, which seems inefficient. OTOH, havingmembers
(etc) be arrays of arrays is uuuuuuugly (and not sure it's even allowed).data_processing_id
? CanRepertoireGroup
s get their ownDataProcessing
objects?Other remaining tasks before this can be merged:
Clone
s