Closed anandaroop closed 7 years ago
Based on our conversation yesterday, I thought that maybe this wouldn't be needed if we have a combination of structured URLs to save searches + the ability to search existing time stamps such as updated_at
, created_at
, or last_genomed_at
? Please correct me if I'm wrong here, or if this is an exploratory issue!
(sorry for accidental close, oops!)
Good point!
I'm still a little unsure how this will all play out under real-world usage (e.g. the last_genomed_at
field will get updated by one-off updates in Helix, so wouldn't be reliable as an indicator of the last batch update).
So let's keep the issue open for future exploration, at a lower priority for now.
Indeed! re:
I'm still a little unsure how this will all play out under real-world usage
I am totally there with you as well, having a hard time thinking about how all these cases intersect. I'd also support keeping it open for exploration, prioritizing search by existing timestamps over it. 👍
Confirming here that we're going in a different direction to manage the genoming workflow in Rosalind, but that we are interested in keeping a paper trail of batch update activities, for the sake of best practices and in case of a need to roll back or backtrack an update. I'll open a separate issue for that!
A user should be able to filter artworks by a timestamp that represents the time it was last batch-updated via Rosalind.
So maybe a
batch_updated_at
field on the Genome model?If so, that timestamp would exist on each genome: default, provisional, automated, partner. So it's TBD if and how we would treat all these variants — for updating, and for searching against.