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?
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With