Re: Forcing Core Data to save attribute changed behind its back?
Re: Forcing Core Data to save attribute changed behind its back?
- Subject: Re: Forcing Core Data to save attribute changed behind its back?
- From: Quincey Morris <email@hidden>
- Date: Tue, 24 Jul 2012 14:04:12 -0700
On Jul 23, 2012, at 15:03 , Sean McBride wrote:
> I have a managed object where one of the attributes is quite large and so when I change it, instead of the usual setAttribute:newValue I mutate the object directly. Of course, Core Data does not know that I've done this. I'm looking for a way to tell it. (Otherwise, if the thing is mutated after the document is first saved, Core Data cleverly skips updating this attribute.)
>
> I've tried:
> - setAttribute:sameValue
> - will/didChangeValueForKeyPath: but that's not a sufficient 'kick'
I believe the answer is that you're Doing It Wrong™. :)
Core Data attributes are based on value-objects -- that is, Core Data by design assumes that attribute values are immutable (at least as far as what they represent, even if not literally immutable value objects)**. I vaguely remember this coming up on this list a couple of years ago. The only documentation reference I can find now is this:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdUsingMOs.html#//apple_ref/doc/uid/TP40001803-212651
which says:
> You must, however, change attribute values in a KVC-compliant fashion. For example, the following typically represents a programming error:
>
> NSMutableString *mutableString = [NSMutableString stringWithString:@"Stig"];
> [newEmployee setFirstName:mutableString];
> [mutableString setString:@"Laura"];
>
> For mutable values, you should either transfer ownership of the value to Core Data, or implement custom accessor methods to always perform a copy. The previous example may not represent an error if the class representing the Employee entity declared the firstName property (copy) (or implemented a custom setFirstName: method that copied the new value). In this case, after the invocation of setString: (in the third code line) the value of firstName would then still be “Stig” and not “Laura”.
By "transfer ownership", this seems to mean "don't keep a reference to it, so that you don't change it, so that it's effectively immutable", which is my justification for the explanation I first gave.
Another way of saying all this is that it may not be possible to (reliably) inform Core Data that an attribute has changed without changing the identity of the object that represents the value.
** I think the same is intended to be true of @properties that represent attributes generally, not just with Core Data. An attribute value is paradigmatically immutable, whereas a mutably-valued @property is really a to-one relationship, not an attribute. Core Data is just a stern follower of this principle.
_______________________________________________
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