CurationV1 does not track a metrics source.

[samuelbray32]

Describe the bug

• The table CurationV1 sources metrics manually passed by the user in insert_curation to make the table entries.
• As far as I can tell, there is no way to go back and trace where those metrics came from
  • makes it hard for reproducibility
  • adds risk of data integrity due to user error at insert
  • makes it hard to select a Curation entry based on upstream features in the future

Solutions Brainstorm

• The v0 pipeline had a similar need to not make a formal dependency on metric source in Curation
  • data integrity due to user error partially solved by making the population of Curation done in AutomaticCuration.populate.
  • Could potentially add similar functionality in the population of MetricCuration

[khl02007]

@samuelbray32 This is true. One solution I had thought of (and had implemented) is to make a column in CurationV1 that tells you where it came from and provide a method to define it. For example, once you have populated MetricCuration and you want to do another curation, you can use insert_metric_curation method of CurationV1 which inserts metric curation id in the description field (https://github.com/LorenFrankLab/spyglass/blob/35335fbc339d1b7fbfb64bc54947a7bcbf31ad62/src/spyglass/spikesorting/v1/curation.py#L163). Of course this only works if the user uses this method. And if you delete a row in MetricCuration, it doesn't automatically find the associated row in CurationV1 and delete that (that was something I had planned to implement but didn't).

But this solution is not very elegant and I'm open to suggestions.