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 (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
