Fetched Properties v Relationships (Core Data - iPhone)

Question

I\'m a new iPhone developer (of about 4 months or so) who is starting to look at Core Data.

In the \"Beginning iPhone 3 Development\" book by Dave Mark it

Answer 1

From the "Core Data Programming Guide", fetched properties represent "weak, one-way relationships". They simply allow you to define the value of a property with a fetch predicate rather than modeling it directly like a relationship.

One major difference is that fetched properties are not live or dynamic like direct relationships. You must explicitly keep fetched properties up-to-date by manually refreshing the object containing the fetched property when changes occur in your object graph that will affect the value of the fetched property.

Answer 2

I would highly recommend Core Data, by Marcus Zarra. I picked it up a few months ago, and while it is assumed you have some Objective-C experience, it's fairly accessible for beginners too.

Answer 3

Check out faulting in Core Data:

Using faults, if you retrieve a single Employee object from a persistent store its manager, department, and reports relationships are initially represented by faults. Although the fault is an instance of the Department class, it has not yet been realized—none of its persistent instance variables have yet been set.

If you send the Department object a message to get, say, its name, then the fault fires—and in this situation Core Data executes a fetch for you to retrieve all the object's attributes.