On 25/09/2013, at 1:05 PM, Paul Hoadley <
email@hidden> 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 <
email@hidden> 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?