Chuck forgot to hit Reply All...
On 25/09/2013, at 1:05 PM, Paul Hoadley <pa...@logicsquad.net> wrote:
> I have a Callable task that runs in the background. It needs an array of EOs
> to produce a report. Is it sufficient to localInstance all of those EOs into
> their own newly-created EC just for the task, or _must_ they be handed over
> to the background task as EOGlobalIDs? (If the latter, remind me—why?) Does
> it make any difference if the background task is strictly read-only and never
> calls saveChanges()?
On 25/09/2013, at 1:16 PM, Chuck Hill <ch...@global-village.net> wrote:
> Hi Paul,
>
> localInstance calls globalIDForObject on the _originial_ EC. In theory that
> may not have any bad side effects, but it is not a theory that I would care
> to test. Passing the EOGlobalIDs is definitely safe.
>
> And no, it does not matter what the background EC does. The issue is with
> notifications and changes in a potentially unlocked EC (the original one).
> If you are localInstancing them while you have the original locked, then it
> should be safe, but why not just pass the globalID from a known safe place?
> That is all localInstance is doing anyway.
Thanks Chuck. A quick follow-up:
To be more specific, then, I'm implementing a new background task for the
ERJasperReports.framework which I'm calling ERJRDataSourceReportTask. It's
analogous to the existing ERJRFetchSpecificationReportTask, but takes an
ERJRFoundationDataSource instead of a fetch specification. For our purposes
here, we probably only need to know that the latter just takes an NSArray<?
extends NSKeyValueCodingAdditions>. So here's part of the new class:
public class ERJRDataSourceReportTask implements Callable<File>,
IERXPercentComplete {
public ERJRDataSourceReportTask(ERJRFoundationDataSource dataSource,
String reportName) {
// ...
}
Ideally I'd like to keep it general like this (that is, accepting
ERJRFoundationDataSource in the constructor), but what happens in the specific
case where the NSArray<? extends NSKeyValueCodingAdditions> backing that is
actually an NSArray<EOEnterpriseObject>? Should I look for that specific case
(in the task's constructor above), then pull out all the EOGlobalIDs, and then
re-create all the EOs via those EOGlobalIDs right there on the spot? I mean,
presumably this is equivalent to having the caller supply an array of
EOGlobalIDs (because the _constructor_ is running in the same original thread),
but what I've just described sounds ridiculous, doesn't it?
What I would like to avoid is a special-case constructor accepting
NSArray<EOGlobalID>, but I could do that if I had to. Any thoughts?
--
Paul Hoadley
http://logicsquad.net/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
