Amen. I recently did a little media database app because I was convinced a custom schema and indexes would make searches faster. By the time I had it working I’d succeeded in writing half-assed versions of NSPersistentStore and NSManagedObjectContext, NSPredicate (complete with formatted text parser!), NSFetchRequest, NSManagedObject and I’d begun the great quest of rewriting CD’s migration infrastructure.

And I’m really not sure it runs that fast.

That’s my tm’d manta. Have you ever worked with a SysAdmin in the past 10 years. Me neither! That’s because AWS, Rackspace, Azure and others have replaced the need to ‘own’ machines. (I hated those otherwise useless guys that knew a handful of terminal commands.)
The ongoing switch now is to toward a higher level or service, or a complete data storage rather than a raw machine, a la Parse, Stackmob and so forth. Now that gets rid of your back-end developer.
Good new and bad news. Good news: Why rewrite the effectively the same damn backend over and over again. Bad news: You get rid of a whack of seasoned developers and your firm is run by script-kiddies.
On an end note, I find Core Data to be utterly awesome while EJB killed Java.

You’re right, I really need to document CDH better. It’s in the “saves me time” stage, but not yet in the “recommended for third-party reliance” stage of the lifecycle. Working on it.

From CoreData’s point of view, the reference object is like a “key” that identifies an object. When a fetch request comes in, and you want to serve 50 objects, you create (or re-use) 50 reference objects (which can be any NSCopying-compatible object), wrap them up in NSManagedObjectIDs, and serve them up. When it comes time to save the object, you are told the NSManagedObjectIDs and you extract your original reference object, and in this way you know specifically what object(s) the user saves (or deletes).

The naive thing to do here is (assuming you are talking to a remote database) is just to use its foreign key as a reference object, because that’s probably what the remote machine wants to process any update, save, delete, etc.

The additional complexity in CDH comes because I am interested in supporting more aggressive caching scenarios (such as batched writes) in which you might not know, at the time that you “save” the object, what the foreign key actually is. I also see a more general problem: that of tracking objects not merely between one server and one client database, but in multiple stores on the client side and potentially on multiple servers, which makes building powerful software out of reusable building blocks easier, and CDH uses multiple databases internally already, which is much easier to debug. So I am using “uniqueID” in CDH to mean a unique identifier that is independent of the particular database in which an object is stored, and this is something that can really only be provided by the application because remote servers might dictate their own identifiers.

You advised @Quinn to look at https://github.com/drewcrawford/CoreDataHelp/blob/master/CoreDataHelp/DCACacheIncrementalStore.m#L91 to see how. And I’m just hoping you can elaborate on what’s happening there. You have a protocol, which defines a method uniqueID, however, there is no implementation of this method in the code. So… can you explain what the reasoning here is?

Perhaps you’d find my latest project to be close to what you were imagining: https://github.com/AFNetworking/AFIncrementalStore