On Jun 10, 2005, at 4:24 AM, Nicko van Someren wrote:
On 10 Jun 2005, at 10:23, mmalcolm crawford wrote:
On Jun 10, 2005, at 1:55 AM, Nicko van Someren wrote:
I appreciate that one is not a crippled copy of the other.
It's not clear, then, why you wrote that one is a crippled version of
the other.
Also note: WebObjects is bundled for free with the Developer Tools...
Really? WO is available as a download for paid-up commercial
developers through ADC Select and Premier membership but I don't
see any sign of it in the free developer tools.
Umm, yes, really. WebObject 5.3 was announced at WWDC. It is
bundled free with the developer tools. The deployment license is
bundled with Mac OS X Server.
This is fine until you have two applications accessing the same
data at the same time at which point the memory cache and the
file will get woefully out of sync and "bad things" will happen.
This ("bad things" will happen) is not the case. Just like EOF,
Core Data is designed to properly detect and deal with situations
in which the persistent store is modified by another application,
and there are well-specified patterns to follow if this occurs.
Really?
Again, yes, really...
On the page of the link you gave above, under the heading Change
Management it says:
"There is an important behavioral difference between EOF and
Core Data with respect to change propagation. In Core Data, peer
managed object contexts are not "kept in sync" in the same was as
are editing contexts in EOF. Given two managed object contexts
connected to the same persistent store coordinator, and with the
"same" managed object in both contexts, if you modify one of the
managed objects then save, the other is not re-faulted (changes are
not propagated from one context to another). If you modify then
save the other managed object, then (at least if you use the
default merge policy) you will get an optimistic locking failure."
This represents a subtle but important change in the specified
pattern of behavior -- it does not mean that something "bad" is
happening. You're confusing change propagation *within the stack*
with change propagation between the database and your application...
Clearly then there is no change propagation even if we are talking
through the same Persistent Store Coordinator, let alone if we are
accessing the same file from two different applications on two
different machines over a network.
There is no change propagation in EOF either, *from the database to
the access layer*.
It's not clear to me that you understand the way EOF deals with
optimistic locking failures. Perhaps you could explain what it is
you perceive to be the difference between the way EOF and Core Data
deal with an external change to the persistent store?
mmalc
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
