Core Data on Cocoa Unbound
The quality of the posts on the new cocoa-unbound list has been high. Recently there has been some discussion related to Brent Simmons’ On Switching Away From Core Data. Landon Fuller writes:
CoreData attempts to tightly weld these two different abstract representations together, attempting to allow developers to leverage their single application model as both an on-disk serialization as well as an in-memory representation. Unfortunately this abstraction is extremely leaky, and Core Data’s requirements spread pervasively through the application’s in-memory model…
I think this is a real issue. His solution is to avoid Core Data. My approach has been to sometimes use an additional layer of application objects atop the Core Data ones, along with my own notifications and change tracking. That is, leverage as many Core Data services as possible, but recognize that sometimes it’s more efficient or makes the code simpler to use it more like a “dumb” storage layer than a manager of your entire object graph.
Ben Trumbull on the common problem of objects that have unique IDs from outside of Core Data:
Import the new objects in batches instead of 1 at a time. Instead of looking up existing with O(N) fetches, use an IN clause on a respectable batch size, like 500 or 1000. This is the database equivalent of the 1000 x read(1 byte) v.s. 1 x read(1000 bytes). “insert or replace” style uniquing has substantial issues when it comes to object identity and relationship maintenance. It’s pretty easy to bork your foreign keys this way. People sometimes try to cheat out on that by then using their unique criteria as the primary key itself. So they fix the FK maintenance by some indirection. And pay for it by having slower everything else all the time.
