Re: Multi-User using Core Data?
Re: Multi-User using Core Data?
- Subject: Re: Multi-User using Core Data?
- From: mmalcolm crawford <email@hidden>
- Date: Sat, 11 Jun 2005 19:27:47 -0700
On Jun 10, 2005, at 11:17 AM, Nicko van Someren wrote:
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.
"Cripple" implies that there is functionality that is present and
complete, but which is deliberately turned off. This is simply not
the case.
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.
There are many reasons why this may be the case, not least because
the implementation may not be considered sufficiently well abstracted
to allow subclassing, or because the API is not finalised. There are
many examples of functionality being restricted to private frameworks
for precisely these reasons...
I suspect that you misunderstand or do not fully appreciate what is
involved here. In many respects, the current Java implementation of
EOF is made much easier because of JDBC. EOF is able to make use of
a single JDBC adaptor, and database developers provide custom drivers
below that to support communication with their product. It may be
instructive to look at the documentation for WebObjects 4.5: <http://
developer.apple.com/documentation/LegacyTechnologies/WebObjects/
WebObjects_4.5/webobjects.html>
In particular note:
InformixEOAdaptor
ODBCEOAdaptor
OracleEOAdaptor
SybaseEOAdaptor
In principle, each database requires its own adaptor, client
libraries etc. In practice, it may be sufficient to implement an
ODBC adaptor, but that still requires third party support...
In summary, however, it's untrue to claim that Core Data is
"crippled" -- there is a considerable amount of extra work that would
be required to support additional persistent store types...
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.
Bill would be better able to comment on the file-level locking issues
here. In general, however, Core Data (as EOF) uses optimistic
locking to ensure that two users do not overwrite the same data.
This does not rely on file (or row) locking...
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...
Please submit enhancement requests.
When doing so, it would be very useful if you could indicate, for
example, how critical such functionality is to your product, how many
users you believe you could bring to the platform if such
functionality were provided, and the relative importance of such
functionality -- e.g. given a choice between support for ordered
relationships and database adaptors, which *one* would you choose?
Note: The preceding example is purely an *example*. This should not
in any way be taken to suggest that this choice would be one that
would be made in practice, nor should it be taken to suggest that
Apple might provide either or both features in the future. It is
intended to highlight the fact that there are clearly resource
constraints, and that in any given release cycle there is a limit to
the amount of new functionality that can be implemented. I'm sure
the team would love to implement all the features that everyone is
asking for, but this is simply not possible. Feedback from the
developer community is very useful in determining priorities...
mmalc
To emphasise: Speaking only for himself.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden