Re: Copying Managed Objects from App to Doc MOContext
Re: Copying Managed Objects from App to Doc MOContext
- Subject: Re: Copying Managed Objects from App to Doc MOContext
- From: Ben Trumbull <email@hidden>
- Date: Tue, 28 Jul 2009 16:07:58 -0700
On Jul 28, 2009, at 3:59 PM, Jerry Krinock wrote:
Last December I asked a question here regarding how I should copy
attributes from an existing managed object to a new managed object,
when it is necessary to create this new object in a different
managed object context. I noted that getting an "attributes
dictionary" from the existing managed object using [self
dictionaryWithValuesForKeys:attributes], and then iterating over
this dictionary to setValue:forKey: in the new managed object did
not seem to be satisfactory since that method returns a dictionary
containing an NSNull value for keys that were nil, instead of
omitting them. I posted the code I was using instead [1].
But then, on 2008 Dec 22, at 00:18, Ben Trumbull wrote:
We tried omitting pairs with nil values, and stuff broke. Like
views didn't get updated because iterating over the values during
setting with (nil = missing) meant nil values didn't get reset.
Like with undo or bindings. Your setter here has that issue. You
may prefer that behavior, but we found it even more problematic
than forcing clients to check for NSNull.
Yesterday I finally got around to trying what I believe to be Ben's
way, which is to set attributes that are nil in the existing object
to [NSNull null] in the copy. But Core Data doesn't seem to like
that -- for example, I have an attribute named 'comments' of type
string, and when copying an object which has nil comments,
attempting to setValue:[NSNull null] forKey:@"comments", I get this...
Unacceptable type of value for attribute: property = "comments";
desired type = NSString; given type = NSNull; value = <null>
Apparently I've misunderstood Ben. What was he trying to tell me?
If the value from the dictionary is NSNull, you need to use nil
instead. Accessor methods don't accept NSNull in place of NSString.
The swapping has to happen in your copy/snapshot code. The NSNull
issue is unfortunate, but your alternative is not copying nil values
at all since they won't be in the dictionary. For creating new
objects, that's not a problem. But for restoring previous state over
an existing object, that's undesirable.
There are other more complicated approaches, but ultimately handling
NSNull in your restore code is the least bad approach.
- Ben
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden