Replace all the cached fields with MaintainedModel fields

[lparsons]

FEATURE REQUEST

Inspiration

Cached fields/model properties are not searchable, but the new MaintainedModel paradigm solves the same problem: it keeps fields updated when changes are made to records in related tables, and it uses real fields that are searchable.

Description

Replace all the cached fields with MaintainedModel fields. This will require modification to how MaintainedModel propagates changes. The existing case only changes from the initially changed record upward (names in TracerLabel->Tracer->Infusate). New requirements will involve downward propagation and Models without maintained fields that must pass changes up or down.

Alternatives

none

Dependencies

This issue cannot be started until the completion of the following issue(s):

• 395

• 398

• 477

• 553

Comment

C. It just occurred to me that we could make num_tracers a maintained field. Perhaps a new issue?

_Originally posted by @hepcat72 in https://github.com/Princeton-LSI-ResearchComputing/tracebase/pull/453#discussion_r905359660_

---

ISSUE OWNER SECTION

Assumptions

• Links to child records will only be supplied in the MaintainedModels decorators if updates exist in a model below that model. In other words, if links to child records are supplied, they will always be traversed to propagate updates even if no fields to update exist in those child records
• The order of update propagation (1. self, 2. children (if links exist), and 3. parent) will suffice for all maintained fields

Requirements

• [x] 1. Fields are updated in a specific order, originating from the initially saved record downward, then upward, in the following manner:
  1. Update fields in current record
  2. If child links exist associated with the update being performed, loop through the child records (that were not the child that triggered this update) and trigger their updates, telling them that those updates were triggered from the parent
  3. If a parent link exists and this update was not triggered by that parent, trigger its update, telling it which child triggered its update
• [x] 2. Updates of Infusate.name, Tracer.name, and TracerLabel.name still work and update from changed record upward
• [x] 3. Updates of FCirc.is_last, Sample.is_serum_sample, and Animal.last_serum_sample are triggered by themselves and by changes to models down to PeakGroup.
• [x] 4. Ability to propagate changes without a function decorator if no maintained fields are present
• [x] 5. Ability to apply multiple propagate-only decorators with different propagation patterns and different labels

Limitations

• Does not create or delete records of classes derived from MaintainedModel - only manages the value of fields in existing records.

Affected Components

• DataRepo/models/animal.py
• DataRepo/models/animal_label.py
• DataRepo/models/fcirc.py
• DataRepo/models/infusate.py
• DataRepo/models/infusate_tracer.py
• DataRepo/models/maintained_model.py
• DataRepo/models/ms_run.py
• DataRepo/models/peak_group.py
• DataRepo/models/peak_group_label.py
• DataRepo/models/sample.py
• DataRepo/models/tracer.py
• DataRepo/models/tracer_label.py
• DataRepo/models/utilities.py
• DataRepo/utils/accucor_data_loader.py
• DataRepo/utils/sample_table_loader.py

DESIGN

Interface Change description

None

Code Change Description

The existing MaintainedModel code only propagates updates to parent records when a particular update to a model object is made, however, with FCirc.is_last_serum_peak_group, FCirc does not have a child record reference and additions of peakgroups to other serum samples, or additions of serum samples themselves, would necessitate changes to sibling and/or nephew records, so changes need to be able to be propagated to child records. I implemented this in such a way that if the decorator has child fields supplied to it, changes will propagate to children first (dfs) and then up to parents. Loops are prevented by passing along an updated reference that contains record signatures.

Tests

1. [unnecessary] Related records are updated
2. [existing tests] Updates of Infusate.name, Tracer.name, and TracerLabel.name still work and update from changed record upward
3. Updates of FCirc.is_last, Sample.is_serum_sample, and Animal.last_serum_sample are triggered by themselves and by changes to models down to PeakGroup.
   1. Create a new serum sample whose time collected is later than existing serum samples.
      • [x] 1. Confirm all FCirc.is_last values are unchanged.
      • [x] 2. Confirm the new sample's Sample.is_serum_sample is True.
      • [x] 3. Confirm Animal.last_serum_sample points to the new sample.
   2. Create a new msrun whose date is later than the msrun of the new serum sample (created above), a new tracer peak group in the new serum sample (created above), and related peak group labels.
      • [x] 1. Confirm all FCirc.is_last values related to the old serum sample are now false.
      • [x] 2. Create new FCirc records for the new serum sample, tracer, and label(s); and confirm each record's FCirc.is_last is true.
      • [x] 4. Add a confirmation to the above tests that there exists no maintained_field_function decorator applied to PeakGroup
4. [unnecessary] Ability to apply multiple propagate-only decorators with different propagation patterns and different labels

[hepcat72]

ToDo:

• [x] I temporarily changed access from Sample.is_serum_sample to Sample._is_serum_sample during test fixing because I haven't implemented the update of that field yet. Change those instances back
• [x] Implement the propagation of field updates

[hepcat72]

It would probably be good to suspend cache updates (and access) during the propagation of maintained model updates, though I'm not sure how best to do that without making MaintainedModel dependent on HierCachedModel... I may be able to manually suspend cache activities in each maintained_field_function, but since the goal is to replace all those cached fields with actual fields, that would be somewhat of a waste of time... I'll just punt on this.