Deletion+processPendingChanges+transient attributes

FROM : Quincey Morris
DATE : Wed Apr 02 04:06:55 2008

I was surprised to see a Core Data object throw an exception during 
'processPendingChanges' because the object couldn't handle 
'setValue:nil forKey:'.

AFAICT, this happened under the following conditions:

-- the object had been inserted into the managed object context
-- the object had then been deleted from the context (some of the 
objects being created eventually get deleted)
-- no save had ever been done to the persistent store
-- 'processPendingChanges' was in the middle of faulting out the 
object that had been deleted
-- 'processPendingChanges' was trying to set every attribute of the 
object to nil
-- the attribute in question was of type 'undefined' and marked 
transient
-- there were custom accessors for the attribute's key that get and 
set it as a NSRect

(I don't think it matters how the object came to be deleted -- I 
suspect that the same exception would occur whenever it was deleted 
from the context. Also, the undefined/transient attribute with custom 
scalar/struct accessors is a standard Core Data coding pattern. I 
copied the code from the documentation.)

What's surprising about this is Core Data's apparent assumption that 
an 'undefined' attribute is nevertheless represented by some kind of 
Objective C object, and is therefore setting it to nil is safe. 
Clearly, in this case, there is no object and setting the attribute to 
nil is senseless, and I would have expected Core Data not to try 
anything tricky like this precisely because the attribute's type is 
'undefined'.

So is this to be regarded as a bug in Core Data? A bug in my 
understanding?

(I had earlier noticed and worked around a cousin to this issue: if a 
transient/undefined attribute is implemented by a managed object that 
can return nil for the corresponding key, then there's a validation 
error at save time if the attribute is not also marked optional. 
Again, if the attribute type is 'undefined', I would have expected 
Core Data to make no assumptions about how to interpret the value of 
the key.)