• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Clarification on passing EOs to background threads
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Clarification on passing EOs to background threads


  • Subject: Re: Clarification on passing EOs to background threads
  • From: Paul Hoadley <email@hidden>
  • Date: Wed, 25 Sep 2013 14:32:02 +0930

Chuck forgot to hit Reply All...

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?


-- 
Paul Hoadley
http://logicsquad.net/



 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Clarification on passing EOs to background threads
      • From: Paul Hoadley <email@hidden>
References: 
 >Clarification on passing EOs to background threads (From: Paul Hoadley <email@hidden>)

  • Prev by Date: Clarification on passing EOs to background threads
  • Next by Date: D2W have you seen this
  • Previous by thread: Clarification on passing EOs to background threads
  • Next by thread: Re: Clarification on passing EOs to background threads
  • Index(es):
    • Date
    • Thread