Not that I know the original poster's development situation, but for
those of us writing client-server multi-user enterprise database Cocoa
apps, there's really no Apple-provided solution right now; running
SQLLite and Core Data on a local machine isn't going to cut it. Even
if Apple were to some day include real database support for Core Data
in 10.9 (or whatever it will be), there'd still be the issue of legacy
databases that may not take kindly to the idea of extra tables and
stored procedures being added to the database to support graph
management (like BaseTen currently does), or that would make use of
views, stored procedures, and set-returning functions which a future
database-friendly Core Data may not support. This legacy database
problem will be especially pressing if the mac gets enough enterprise
market share and businesses switch their clients for existing
databases over to the mac.
So I think that having to write your own Cocoa object graph management
and persistence framework is a realistic and necessary evil, and in
fact, I'm having to write my own PostgreSQL framework to do this kind
of thing right now.
-- Ilan
On May 10, 2008, at 9:53 PM, Chris Hanson wrote:
The question is, of course, why not just use Core Data if you're
going to be doing object-graph management? It's not a "beginner"
technology, but that is what it's for, and the original poster would
probably do well to take a look at it before going to far in the
direction of implementing a completely different object graph
management and persistence framework.
_______________________________________________
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 [EMAIL PROTECTED]
