I try to minimize my dependency on CoreData by using generic and app-specific categories on the MOC. I also mostly use root entities, rather than doing independent fetches. I had looked at other options, but pragmatism won out, and I went with CoreData.
You mentioned MacApp. I was heavily involved in that for awhile and even got into the credits. I don¹t know if you remember Bob Krause. When I was running the developer sig at LA Mac Group, I had him down for a presentation on his object database backend, NeoAccess. He had a version for MacApp, but I believe he also had one for Next Step. I tried to get Apple, Inc. to look into it, but I guess they decided to go with their Enterprise Objects to do CoreData instead. I wish they would take another look and consider doing a true object database engine using more of a CORBA-type interface, which, I believe, was attempted by Taligent, before Jobs killed it. On the original question asked in this thread, I have several similar places where I use a root object to also persist an object selection in the referenced collection. I could not see burdening the collection objects with another inverse relationship, so I just let these dangle, and ignore the compiler¹s complaints, because this is something that can usually be recovered from if there is a problem. On 6/22/13 2:00 PM, Michael Crawford <mdcrawf...@gmail.com> wrote: > I don't use Core Data because it's not cross-platform. In my honest opinion > no one in their right mind would bet their livelihood on platform-specific > document formats, no matter what the platform. I used to be a Senior Engineer > at Apple. Many of my best friends still work for Apple. But I remember > Bedrock. I remember MacApp. I actually led the effort to specify an Apple > Events Suite, along with a bunch of my employer's competitors. The Word > Services Suite still works completely unmodified in Mac OS X, despite my > having written the spec in 1992. Now try to find any mention of Apple Events > in any of Apple's documentation. While one can use SQLite or XML for the > storage, if the SQLite or XML documents are to be opened on some other > platform, one would have to write all that code from scratch, without the use > of Core Data. Instead for SQLite, I just write the SQL directly, and for XML, > I use Xerces-C (actually C++) to create a DOM tree (Document Object Model) in > memory, then serialize it to an XML file. The inverse process reads XML then > creates an in-memory DOM tree. For large files, Xerces-C also implements SAX > (Simple Architecture for XML), which uses callbacks for each item in the file; > say for XHTML, one would have a <title> handler, a </title> handler, a <body> > handler, a </body> handler and so on. It's more difficult to write Sax code, > but it's far faster and uses far less memory than DOM. Mike _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
