Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add job ID to result object #1967

Open
blakejohnson opened this issue Oct 11, 2024 · 4 comments
Open

Add job ID to result object #1967

blakejohnson opened this issue Oct 11, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@blakejohnson
Copy link
Contributor

blakejohnson commented Oct 11, 2024

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 property result.job_id. To be consistent with current ways of spelling things, I suppose this ought to be a method, result.job_id().

Open questions:

  1. Do we implement this by populating the metadata field of the result objects, while still making it accessible via a class method, or
  2. Do we update the result schema so that Job ID becomes a formal part of the schema?
@blakejohnson blakejohnson added the enhancement New feature or request label Oct 11, 2024
@jyu00
Copy link
Collaborator

jyu00 commented Oct 15, 2024

@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.

@kt474
Copy link
Member

kt474 commented Oct 17, 2024

This would have to be done in the Qiskit repo right? That's where the PrimitiveResult class is.

@jyu00
Copy link
Collaborator

jyu00 commented Oct 18, 2024

Having it in Qiskit certainly has the benefit of making it consistent across different primitive implementations. @jakelishman, @mtreinish wdyt?

@jakelishman
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants