What do we break if we fix it now? Since instance id, instance type are
also part of the 'AsyncJobResponse' its appropriate to pass full details.
Clearly from the Ryan use case, details of job are needed by external
systems and since this is the only book-keeping of a job, we need to
retain the hi
He has a point though, why go to the trouble of removing the data to
tell that a job is no longer active, when there's a field that tells
us if the job is active? Was there some other reason?
On Tue, Jul 2, 2013 at 4:42 PM, Kelven Yang wrote:
> Fields in job record are tend to be used to reflect
Fields in job record are tend to be used to reflect job status in job's
life cycle instead of history.
Kelven
On 7/2/13 1:35 PM, "Ryan Dietrich" wrote:
>Ok. I see the "reset attached object" calls now.
>
>I'm curious why those columns are being wiped out. If you wanted to see
>outstanding cal
Ok. I see the "reset attached object" calls now.
I'm curious why those columns are being wiped out. If you wanted to see
outstanding calls for an ID or Type, wouldn't you just query where the
jobStatus is still equal to zero?
Wiping out those columns seems to destroy history, no?
On Jul 2, 2
Ryan,
There's explicit code to remove those two columns. IIRC, the reason is because
asyncjob actually uses those two fields to sequence jobs on the same id and
type. So when the job is done, then it removes those two fields so it doesn't
block the next job.
--Alex
> -Original Message--
Ryan,
Those fields were added to indicate the instances (volumes, vms, etc)
having pending/active async jobs. The customers' main use case was - by
instance id, find out the jobs that are currently being executed for this
instance. Once the job is completed, the field is offset to NULL.
-Alena.
