On Tue, 24 Jul 2012 13:32:21 -0700, Sixten Otto said:
On Tue, Jul 24, 2012 at 11:27 AM, Sean McBride s...@rogue-research.com
wrote:
Yes. My object is a subclass of NSObject and I don't override
isEqual:. As I test, I overrode it and always return NO. At first, I
thought this did the trick,
On Tue, 24 Jul 2012 14:04:12 -0700, Quincey Morris said:
I believe the answer is that you're Doing It Wrong™. :)
I know. :) I only do it in one place, and only because the attribute is a few
hundred MB, which I don't want to be copying all the time.
(The official Core Data recommendations for
On Wed, Jul 25, 2012, at 03:54 PM, Sean McBride wrote:
On Tue, 24 Jul 2012 14:04:12 -0700, Quincey Morris said:
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
On Mon, Jul 23, 2012 at 3:03 PM, Sean McBride s...@rogue-research.com wrote:
when I change it, instead of the usual setAttribute:newValue I mutate the
object directly.
- will/didChangeValueForKeyPath: but that's not a sufficient 'kick'
Out of random curiousity, does this big mutable object
What do you try to win by changing the attribute bind CD's back?
If you want to take it out of undo you might switch it off temporarily (e.g.
[undoManager disableUndoRegistration], or store the undo manager in a local,
set the context's undo to nil, and restore it - which may or may not cause
On Tue, 24 Jul 2012 15:15:16 +0200, Peter Hartmann said:
What do you try to win by changing the attribute bind CD's back?
Run time performance. The data is large and changes frequently.
If you want to take it out of undo you might switch it off temporarily
(e.g. [undoManager
On Tue, 24 Jul 2012 05:31:22 -0700, Sixten Otto said:
when I change it, instead of the usual setAttribute:newValue I mutate
the object directly.
- will/didChangeValueForKeyPath: but that's not a sufficient 'kick'
Out of random curiousity, does this big mutable object you're updating
change in
On Tue, Jul 24, 2012 at 11:27 AM, Sean McBride s...@rogue-research.com wrote:
Yes. My object is a subclass of NSObject and I don't override isEqual:. As
I test, I overrode it and always return NO. At first, I thought this did the
trick, since Core Data passed through this and saved
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
Hi all,
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
10 matches
Mail list logo
