Renaming and saving run results

[brimoor]

Change log

• Adds support for renaming runs via rename_annotation_run(), rename_evaluation(), and rename_brain_run()
• Adds an optional type argument to list_annotation_runs(), list_evaluations() and list_brain_runs() to retrieve runs of specific type (eg similarity indexes or visualizations within the full set of brain keys)
• Adds save() method to all RunResults objects that allows for saving updates to results to the database

[codecov]

Codecov Report

Patch coverage: 74.28% and project coverage change: -12.82 ⚠️

Comparison is base (02bb409) 61.40% compared to head (4e907a1) 48.58%.

Additional details and impacted files

@@             Coverage Diff              @@
##           develop    #2696       +/-   ##
============================================
- Coverage    61.40%   48.58%   -12.82%     
============================================
  Files          256      236       -20     
  Lines        42954    32146    -10808     
  Branches       349      349               
============================================
- Hits         26374    15619    -10755     
+ Misses       16580    16527       -53     

Flag	Coverage Δ
app	48.58% <74.28%> (+0.16%)	⬆️
python	?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
app/packages/state/src/recoil/aggregations.ts	34.17% <0.00%> (ø)
app/packages/state/src/recoil/selectors.ts	45.92% <48.48%> (-3.49%)	⬇️
...es/components/src/components/ExternalLink/index.ts	100.00% <100.00%> (ø)
...ges/components/src/components/IconButton/index.tsx	100.00% <100.00%> (ø)
...ages/components/src/components/Tooltip/Tooltip.tsx	23.94% <100.00%> (+6.61%)	⬆️
app/packages/components/src/components/index.ts	100.00% <100.00%> (ø)
...mutations/__generated__/setViewMutation.graphql.ts	100.00% <100.00%> (ø)
app/packages/relay/src/mutations/setView.ts	100.00% <100.00%> (ø)
app/packages/state/src/recoil/atoms.ts	89.42% <100.00%> (-0.07%)	⬇️
app/packages/state/src/recoil/types.ts	100.00% <100.00%> (ø)
... and 30 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[swheaton]

just one comment about repeated code.
lgtm other than that

[swheaton]

Saw this same method above in multiple classes, can we extract it out somewhere to remain DRY ?

[brimoor]

I was following along with how the cleanup() and get_fields() methods are implemented explicitly on each evaluation protocol.

The implementations for each protocol are currently similar, but there's not an inherent reason why they would always be the same, so I think some repeated code is okay in this case.

[swheaton]

See what you're saying but can't say I agree with the logic. I feel like this is why when we add something to OSS backend we will have multiple places we have to add it to. Which is probably fine if you're making the edit but anyone else might easily miss a spot.

[brimoor]

As it currently is, there are XXXEvaluation base classes for each type of evaluation protocol: classification, detection, regression, segmentation.

The abstraction to remove duplicate code would be "this class of evaluation protocol supports either sample-level or frame-level fields. When processing sample-level fields, it populates a single field whose name matches the eval_key. When processing frame-level fields, it populates a frame-level and sample-level fields whose name matches eval_key." For that class of methods, we could abstract get_fields(), rename(), and cleanup() into a mixin and share the code.

It doesn't seem that useful to me though. Sometimes when there's a bunch of fancy subclass implementations it becomes less clear how to implement a new instance of the interface (eg a new label type to evaluate) because it seems like you have to follow how the base class does some things rather than just doing whatever you need for your case.