EODatabaseContext inner workings (was Re: "Cannot obtain globalId for an object which...")
EODatabaseContext inner workings (was Re: "Cannot obtain globalId for an object which...")
- Subject: EODatabaseContext inner workings (was Re: "Cannot obtain globalId for an object which...")
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 10 Jun 2003 16:56:39 -0500
At 01:53 PM 6/10/2003 -0700, Chuck Hill wrote:
Is there anything in the WO domnentation somewhere about what you write
about database context's active editing context? Just curious. If it's
not, I mayme should file a enhancement report at bugreport.apple.com.
I'm not aware of any such documentation (that does not mean it does not
exist!). I pretty much made that up off the top of my head based on
experience with this exception.
Coincidentally, I have just been studying how EODatabaseContexts work, for
other purposes. What Chuck says is not spelled out clearly (which caused me
plenty of confusion), but the EODatabaseContext documentation only makes
sense if what Chuck says is true. I arrived at the same conclusion myself
in trying to figure out how EODatabaseContext works.
For instance the documentation for
EODatabaseContext.recordChangesInEditingContext makes reference to "the
EOEditingContext that are owned by the receiver." [sic]. The "receiver"
meaning the EODatabaseContext being messaged. And in general, reading
through the various EODatabaseContext methods (and it's delegate methods)
you get the sense that there just MUST be a 'current' EOEditingContext for
everything to work---there are all sorts of methods that must operate on or
with _some_ EC, but no EC is included in an argument. And we know that an
EODatabaseContext can't possibly belong to one single EC in
perpetuity---so, there must be a 'current' EC.
My guess (educated guess, but guess) as to where this 'current' EC is
established is NOT in lock() and unlock(). (Since the EC is not an
argument to 'lock' or 'unlock', I don't see how this could work). My guess
is that the 'current' EC is established in
prepareForSaveWithCoordinator(EOObjectStoreCoordinator c, EOEditingContext
ec), and relinquished when either commitChanges() or rollbackChanges() are
called (or maybe just when unlock() is called? But this seems unworkable).
It's the caller's responsibility, I guess, to call lock() _before_
prepareForSaveWithCoordinator, and call either commitChanges() or
rollbackChanges() followed by unlock() when done. Although it would be
nice if the documentation said that. I guess since they don't expect us to
interact with EODatabaseContext directly (beyond a few documented ways),
they don't think we need to know much about it.
Unfortunately, while we can infer the existence of a database context's
'current editingContext', there doesn't seem to be any API available to see
what this current EC _is_. This lack is in fact what is causing a major
barrier for the functionality I was trying to implement which prompted me
to study EODatabaseContext.
--Jonathan
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
Progress is the mother of all problems.
- G. K. Chesterton
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.