<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div class="im"><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div>
><br>
> #3) Specific to algorithmic complexity - it appears
that jobs are<br>
> keyed by ID, yet accessed using a sequential search
[1] - this does<br>
> not scale well to large numbers of jobs. Is there
no better approach?<br>
</div>
The expectation is there is large amount of data, but the
number of jobs<br>
are not that large. Say we run a reporting job every day,
it is still<br>
one single job with many JobInstance and JobExecution. So
I think the<br>
sequential access is acceptable. I guess another reason I
didn't want<br>
to maintain a mapping is I really don't want to duplicate
the job id as<br>
the key.<br>
</blockquote>
<div><br>
</div>
<div>I'm not sure what you mean by " I really don't want to
duplicate the job id as</div>
the key".</div>
</div>
</div>
</blockquote></div>
The map key is already contained in the associated map value, IOW,
using a field of the value as map key.<div class="im"><br></div></div></blockquote><div><br></div><div>I'm still not sure what you mean. Putting an item into a map does not make a copy of the key. </div><div><br>
</div><div>Stuart </div></div><br></div></div>