we should just write this into Wonder as a util method ...
ERXEOcontrolUtilities convertEOtoGID and convertGIDtoEO should just
support qualifiers.
ms
On Oct 6, 2009, at 2:08 PM, Anjo Krank wrote:
Create a ERXQualifierTraversal, create a new EC, fault the EOs into
it while recombining the qualifier.
Cheers, Anjo
Am 06.10.2009 um 20:03 schrieb Kieran Kelleher:
That's the concern ...... I usually pass GIDs to background tasks,
however in this case, I want to pass an EOFetchSpec to a background
task. So any suggestions on how to cleanly deal with that situation?
Regards, Kieran
On Oct 6, 2009, at 1:59 PM, Anjo Krank wrote:
When you have safelocking on, the EC gets locked and stays locked.
So you session won't be able to access it (if your task is an
ERXRunnable, it not, it's locked/unlocked on demand) and if you
have other locks, too, this might open you to deadlocks.
Cheers, Anjo
Am 06.10.2009 um 19:49 schrieb Kieran Kelleher:
So I have a Callable task that takes an EOFetchSpec. The
FetchSpec is built in the regular R-R context, passed to the
Callable and the Callable is dispatched. The Callable uses the
FetchSpec to fetch the objects in ots own background EC and
perform the processing task. The concern I have is that the
qualifier in the EOFetchSpec will probably have some key value
qualfiers where the "value" is an EOEnterpriseObject, so I am
concerned about EditingContexts. Specifically I am using Wonder's
safelocking ERXEC's everywhere, so I know that when the
EOFetchSpec and its Qualifier(s) are touched in the background
thread, those EOKeyValueQualifier value EO ivars will be in an
unlocked ec. What is the best way to elegantly handle this?
(1) Can those EO object references be converted to faults which
in turn are used in the qualifier and fetchspec
construction? ...... or (2) should I just Serialize the fetchspec
before passing to the background thread and deserialize it
there? ..... or (3) stuff those EO values into the Callable's
editing context before constructing the qualifier (seems
ugly)? ..... or (4) ......?
I had thought EOQualifier might be clever enough to just store
globalIDs of EOs passed in the value param of the constructor,
but Jad indicates otherwise.
Any suggestions?
-Kieran
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/anjo%40krank.net
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40mdimension.com
This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
