Faulting in Core Data

WHY IT EXISTS Core Data manages potentially large object graphs that may not fit comfortably in memory. Loading every attribute and related object up front would be wasteful, so Core Data defers the work until you actually need the data.

THE MENTAL MODEL A fault is a stand-in object. It has a valid identity and object ID but its property values are not yet realized in memory. The managed object exists and can be passed around cheaply; only when you access a persistent property or relationship does Core Data fire the fault.

HOW IT WORKS Firing a fault triggers Core Data to fetch the missing data from the persistent store or the row cache and populate the object. Relationship faults work the same way: a to-many relationship is itself a fault until traversed. This keeps the initial fetch light and the working set small, since untouched objects stay as cheap placeholders.

WHEN IT MATTERS Faulting shines when you fetch many objects but only display a few, or only need a subset of attributes. It keeps memory low and fetches fast.

THE PITFALL If you loop over a large result set and touch a property or relationship on each object, every previously unfired fault hits the store individually, producing an N+1 query storm and surprising slowness. Mitigations include setting returnsObjectsAsFaults to false when you know you will use the data, using relationshipKeyPathsForPrefetching to batch-load relationships, raising fetchBatchSize, or fetching only the needed properties.

COMMON WRONG ANSWERS Describing faulting as eager loading, which is the opposite. Forgetting that relationships also fault. Ignoring the per-object fetch cost when iterating.

ONE CONCRETE EXAMPLE A report sums an amount across ten thousand orders. Fetching returns faults instantly, but the summation loop touches order.amount on each, firing ten thousand individual fetches and stalling. Setting returnsObjectsAsFaults to false on the request, or prefetching the needed attributes, collapses it into a few efficient batches.