Can you explain the advantages of fetching faults instead of just letting the editingContext return them? -SamBarnum

A 'fault' will not actually be fetched until it is asked for. It's just an object in memory that says 'if anyone tries to access my data, I will fetch it from the db.' You usually don't run into a situation where you want to create faults instead of just fetching objects from the EC---but when you're doing complicated programming, it will be obvious when you do. I think just once have I actually manually created faults. [When I had a semantic relationship, but couldn't actually model the relationship, and implemented a sort of half baked relationship scheme of my own instead.]

However, I'm not sure why you'd want to use the above code when the EOEditingContext method faultForRawRow is available. Make an NSDictionary which has pk attribute names as keys and desired values as their values, pass it to yourEC.faultForRawRow?, you've got a fault. A heck of a lot easier than the above.

This method can be used to prefetch relationships in a batch instead of having them fire one by one. This can be used to fine tune batch fetching in code instead of doing it in the model. Be careful of how you use this method. It will force a fetch from the database even if the objects are already cached in the object store. Used incorrectly this can reduce, instead of increase, performance.