views:

39

answers:

1

From the docs: -existingObjectWithID:error:

If there is a managed object with the given ID already registered in the context, that object is returned directly; otherwise the corresponding object is faulted into the context.

This method might perform I/O if the data is uncached.

Unlike objectWithID:, this method never returns a fault.

Well, this is paradox!

They say that -existingObjectWithID:error: may return a fault ("faulted into context"). And at the same time, they say that -objectWithID: does return a fault, but -existingObjectWithID:error: does not. So what's true now? Both method descriptions talk about returning faulted objects.

Can someone clear that up?

+3  A: 

Faulted does not mean "make into a fault". It actually means, "create a full fledged object" the opposite of what you expect. In other words, a faulted object is not a fault. The nomenclature is confusing.

It arises because of the term "to fire a fault" from the old DB days. In that term you took a fault i.e. the ghost of an object and "fired" it thus causing it to load its attributes. This got shorten from "firing the fault" to "faulting" which a naive reader/listener would assume means "to make into a fault."

In training, I've used the term "ghost" as a synonym for fault and "materialize" for faulting. It helps clear up the terminology and expresses my childhood love of Scooby-Do at the same time.

TechZen