Open arielsvn opened 4 years ago
I think you're right! I think we should be able to tell what ProcessorJob
generated a ComputationalResult
. A ComputationalResult
will never have more than one ProcessorJob
associated with it, so it should just be a processor_job_id
property on the ComputationalResult
model, one that we'll probably want to not expose via the API? (I think at the moment we aren't exposing anything about jobs via the API.)
one that we'll probably want to not expose via the API? (I think at the moment we aren't exposing anything about jobs via the API.)
Actually we have endpoints to expose all the jobs: /jobs/downloader
and /jobs/processor
. I started using them to list the jobs for each sample at https://github.com/AlexsLemonade/refinebio-frontend/pull/784. Is there any reason not to expose processor_job_id
in the API? Would be nice to be able to inspect the jobs associated with a ComputationalResult
via the API
Nope, no reason at all! I just thought we were trying to hide those deets from our users but honestly I was hoping that we'd eventually change that anyway :D
Context
Samples can have many
ComputedFiles
, which also haveComputationalResults
.Processor jobs create instances of
ComputationalResult
andComputedFile
when samples are processed.Problem or idea
We have some samples with multiple computed files, but for each one, it's not obvious what original files were used to generate them. Also, there's no way to know which processor jobs generated them.
For example, sample
GSM248431
has multiple computed files.And multiple original files:
Solution or next step
I think it makes sense to add a new relation between
ComputationalResult
andProcessorJob
.Tagging @kurtwheeler for further discussion.