On 10 Jun 2005, at 14:58, mmalcolm crawford wrote:
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.
I didn't. In the same email that points out that the internals of
CoreData are neatly structures to support other sorts of SQL database
I wrote that "... felt it was necessary to "cripple" the freeware
[CoreData] to a specification that is useful for desktop
applications ...". I concede that this might be misinterpreted and
perhaps I should have phrased it better but all I was saying was that
CoreData does not deliver as much functionality as it is clearly
designed to be able to deliver, e.g. it is crippled, which is at odds
with EOF. Even though the underlying structure supports addition of
other sorts of SQL database Apple have kept the API at that level
closed and indeed have taken the trouble of setting classes such as
NSSQLAdaptor as non-exported in the shared library so that it is
difficult to subclass them.
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.
OK, I wasn't at WWDC. What confused me was the way that http://
developer.apple.com/webobjects/ (still) says:
"WebObjects and the Apple Developer Connection
Order WebObjects 5.2 through the ADC Member Site and save over 25%.
Premier members receive one (1) copy free, and may purchase
additional copies for $399 US. Select members may purchase WebObjects
5.2 for $399 US. Please allow 1 to 2 weeks for delivery, depending on
location."
It's nice to know that it's now freely available. Thanks Apple.
...
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...
OK, perhaps I'm missing something but I was under the impression that
the change propagation in EOF worked between instances of
applications, via the database.
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*.
Aha. That was my misapprehension.
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?
Well, my perception was that EOF allowed for triggers on external
changes, which you tell me is not the case, so I guess the point is
moot.
Returning to the original topic of this thread, since you seem to
know something about how this works, can you explain what CoreData
does about implementing it's locking on the SQLite files with a view
to understanding network sharing? SQLite has Shared->Reserved-
>Pending->Exclusive locks and on Unix like machines these are
typically implemented using Posix advisory locks. Advisory locks
have been buggy on NFS for years; if AFP reliably implements
networked locking then things _should_ work if you simply point
multiple programs on multiple machines at a shared copy of the file.
That said, the authors of SQLite explicitly advise against using it
in this way; see the "Situations where another RDBMS may work better"
on http://www.sqlite.org/cvstrac/wiki?p=WhenToUseSqlite where it says
"A good rule of thumb is that you should avoid using SQLite in
situations where the same database will be accessed simultaneously
from many computers over a network filesystem." So we are still left
without a good way to have multi-user access to Core Data files :-
( Perhaps one day Apple will open up the SQL abstraction layer that
lurks within Core Data and either give us the RDBMS adaptors we need
or allow us to write our own...
Nicko
_______________________________________________
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
