Brent’s Persistence Layer
Model objects live on the main thread. This makes it easy to use VSNote, VSTag, and so on in view controllers and in syncing.
There is one exception: you can create a “detached” copy of a model object to use with API calls. A detached model object exists on one thread of execution only, is short-lived, and is disconnected from the database. Detached objects aren’t a factor when it comes to concurrency.
When a model object is added, changed, or deleted, updates to the database are placed in a background serial queue.
Update (2014-03-07): Jesper:
Of Apple’s fixes’ own admission, Core Data sync didn’t work because it was a black box with no ability to debug it. It would be unfair to zing Core Data at large with that epithet. But if it’s something that seems true about Apple’s frameworks, love them mostly as I do, it’s that they’re constructed as if to impress on their user how privileged they should feel because of the difficulty of the bar that they set to solve the problem at, and the complexity of implementation they have used to convincingly solve the problem.
[…]
Basic features are still painful for people that have been successful Cocoa coders for ten years. They’re not sufficiently saved by the ripening of frameworks as much as by their own accumulated ingenuity. Cocoa is still being developed, features are added, but rarely does something hard get easier.
The second reason has to do with my enduring love of plain-ol’ Cocoa. I like regular Cocoa objects. I like being able to implement
NSCoding, overrideisEqual:andhash, and design objects that can be created with a simpleinit(when possible and sensible). I especially like being able to do those things with model objects. (Which totally makes sense.)
1 Comment RSS · Twitter
The parts you chose to quote tell a story. If you want a "detached" object in Core Data, the first thing you do is to not use Core Data. However, the whole weight of Core Data is put into making sure you derive from NSManagedObject and indeed get a ton of benefits for doing so (such as not having to worry about memory management).
I appreciate the reason behind this and the features enabled by it, but the general thrust of "let's have you walk a lot more out of your way so that this will all fit together" does make it "unsafe at any speed" if you occasionally want to keep around objects in shapes just like the real objects. As Brent says, some things just make sense, and getting onboard with Core Data means throwing a whole lot of sense overboard. Whether Core Data will make up for it is up to your use case; considering the brilliant reusability of say most things in Foundation, that's a surprise.
