A common use case is to fetch a transcription corresponding to a given submission.
However, the transcription_set can contain multiple transcriptions, often an additional transcription by the OCR bot.
So, in order to fetch the transcription by the author who completed the submission, we have two options:
Fetch each transcription in the transcription_set and check if the author is equal to completed_by
Search for transcriptions with submission equal to the submission and author equal to completed_by
The problem of these approaches is that we can't efficiently batch our calls by ID.
In the future, we could add an endpoint to fetch every transcription from a list of IDs.
This would be very useful if we want to obtain the transcriptions of a large number of submissions (useful for Buttercup or utility scripts).
The current system would make this quite difficult.
I propose that we add an additional field to Submission, which contains the transcription by the author who completed it.
It could be computed property that is added by the serializer.
This would add a small overhead to the serialization, but potentially save a lot of API calls, which I'd consider as a big win.
A common use case is to fetch a transcription corresponding to a given submission. However, the
transcription_set
can contain multiple transcriptions, often an additional transcription by the OCR bot.So, in order to fetch the transcription by the author who completed the submission, we have two options:
transcription_set
and check if theauthor
is equal tocompleted_by
submission
equal to the submission andauthor
equal tocompleted_by
The problem of these approaches is that we can't efficiently batch our calls by ID. In the future, we could add an endpoint to fetch every transcription from a list of IDs. This would be very useful if we want to obtain the transcriptions of a large number of submissions (useful for Buttercup or utility scripts). The current system would make this quite difficult.
I propose that we add an additional field to
Submission
, which contains the transcription by the author who completed it. It could be computed property that is added by the serializer.This would add a small overhead to the serialization, but potentially save a lot of API calls, which I'd consider as a big win.