Open blakejohnson opened 3 weeks ago
@blakejohnson we can add a result.job_id()
(as much as I hate making it a method), since a job id is needed to pull the result object and therefore is known. Currently it cannot be included in the result returned by the primitives because the primitives don't know about the job id.
This would have to be done in the Qiskit
repo right? That's where the PrimitiveResult
class is.
Having it in Qiskit certainly has the benefit of making it consistent across different primitive implementations. @jakelishman, @mtreinish wdyt?
We can't add new things to an interface after the interface is public for subclassing (these are), unless there's a default implementation of it. There's no default implementation of "job id" we could add that would have any meaning for the user, so it's a problem.
For example: what would the job ID be for a local Aer job?
It could be added in a new interface definition for V3, if we can pin down the semantics of what the ID is supposed to mean.
What is the expected feature or enhancement? I would like primitive result objects to contain a reference to the job ID associated with the result. This is a quality of life improvement that allows me to query to reconstruct the input job if I only have access to a collection of result objects.
For
backend.run
result objects we had a propertyresult.job_id
. To be consistent with current ways of spelling things, I suppose this ought to be a method,result.job_id()
.Open questions:
metadata
field of the result objects, while still making it accessible via a class method, or