Hi Bill,
Thanks for your high-level assessment. I've long admired your
technical skills and writing, so it is with much respect that I
offer some counterpoint. I'm compelled because I have a vested
interest and I love Core Data.
On 18/5/09, Bill Bumgarner <b...@mac.com> wrote:
sticking a SQLite database on a network filesystem and trying to go
multi-user is... just don't do it.
Oops, too late for me. Its been in production at a busy retail
shop for two years. I started the project three years ago after
reading one of your posts defending Core Data and sqlite's
multi-user capability. Then, when it was too late to turn back
I saw your subsequent post warning that it would be a
'nightmare'. Gulp. Its been a challenge but works surprisingly
well, and fast -- dedicated, 'ultra fast' Synology network drive
which claims to be able to saturate gigabit ethernet and has a
buffer 5x the database size.
Combined with the need to provide some kind of a means of making
access to many different vendor's databases transparent
And for what gain? Most of the potential users of (3) will
immediately smack right up against the proprietary -- though
documented, maybe -- schema and find it not-applicable.
"What? I can't just integrate reporting tool X because it
requires the schema to be in THIS form? Fail!".
I'm grateful that EOF's developers and Mr Jobs, in his prime,
didn't let such concerns kill their big dream. At least we have
a fading memory of a modern-day technical miracle. And, of all
the tens of thousands of WebObjects/EOF mailing list posts I
read (many of the best ones authored by you), I don't remember
proprietary database features as a standout issue.
What I have successfully used in the past (and will do so
again, I'm certain), is to use CoreData as a local cache
between the remote data server and my local Object Graph.
Thus, my client/server layer has been quite thin. It simply
Maybe I've been a technocrat for too long, but when I hear the
word 'simply', I begin stepping backward, slowly.
grabs data from the remote server -- in my case, I have used XML-RPC,
but using a SQL client/server would be no different -- and converts it
into the various entities to be shoved into the local CoreData store.
For propagating changes back, CoreData has a complete set of
hooks for figuring out exactly what has changed in the local
store (see the notifications on the various CoreData classes).
Tantalizing. I've noted with interest your mention of those
adventures over the years but have been disappointed that
you've lost the code and that neither you nor Apple, can
provide any such sample code.
However, this brings up (5) :) -- conflict management,
resolution, and merging. It is a hard problem. Don't
underestimate it.
Yesterday, I finished developing a merging system that seems to
have eliminated optimistic-locking and object-inaccessible
exceptions (but I did just see an NSRangeException - Cannot
remove an observer). Its too brute-force to qualify as a real
(5). I offered brief summaries in a recent thread -- basically,
periodic idle-time and as-needed fetch and merge of objects with
recent modification timestamps. You're right though, even that
was hard and is far from perfect (e.g. it may have ruled out
ever implementing Core Data's undo). Also, it can get sluggish
when all the machines are busy. I'm going to speed it up, now
that its working.
Core Data is hot, amazing. I confess sentimentality about how
it carries a little pilot light for the memory of the
magnificent and peerless EOF. Lets leave the door open a crack.
All the best,
Steve
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
