On 2009 Feb 25, at 17:11, Ben Trumbull wrote:
bug numbers ?
Ben, I will definitely file bug(s) after I get this sorted out. But
in the interim...
The problem is easily stated in terms of DepartmentAndEmployees. I
have views which want to know when various object properties change.
For one e
On 2009 Feb 25, at 17:11, Ben Trumbull wrote:
bug numbers ?
Ben, I will definitely file bug(s) after I get this sorted out. But
in the interim...
The problem is easily stated in terms of DepartmentAndEmployees. I
have views which want to know when various object properties change.
Well, that was easy to test and indeed I found that you found a bug in
my idea. The only way to fix it would be if we Apple had given us a -
didUnturnIntoFault method, but they did not.
So, it looks like, for observing changes to the properties of managed
objects ---
* Using NSManagedObjectCon
On Feb 25, 2009, at 7:52 PM, Jerry Krinock wrote:
Note that a fetch will not return deleted objects that might still
be on the undo stack, so I also call
removeSelfFromObserveredObjects from the managed object's dealloc
method.
Oooo, dealloc is not recommended for overriding.
I th
On 2009 Feb 25, at 16:39, Dave Fernandes wrote:
Well, as I mentioned I have stuck with KVO. I don't see why you need
to remove observers when turning into a fault. You only need to
remove observers before the object disappears.
Ah, good point. I was using -didTurnIntoFault since -[NSManag
On Feb 25, 2009, at 14:16, Jerry Krinock wrote:
How can I get this? According to the documentation, a to-many
relationship is ordinarily modified by mutating the mutable set
proxy. So there is no always-invoked accessor to override.
Implement the set-mutation accessor methods in your NSMa
On Feb 25, 2009, at 8:31 AM, Jerry Krinock wrote:
So, it looks like, for observing changes to the properties of
managed objects ---
* Using NSManagedObjectContextObjectsDidChangeNotification is no good
since it doesn't give you specific information on the current
change
which a
On 2009 Feb 25, at 16:19, Dave Fernandes wrote:
Yes, the one fetched from the persistent store may still be a fault
if you have not tried to access any attributes yet.
Further testing shows that it does become a fault if I change an
attribute and then delete the Employee. That's ^changing
On Feb 25, 2009, at 3:51 PM, Jerry Krinock wrote:
Dave's earlier comment on this contains some assumptions that are
suspect. I don't know of any guarantee that deleting an object
causes the object to first be faulted out and/or to receive a
'didTurnIntoFault' message, but perhaps it's so
On Feb 25, 2009, at 2:24 PM, Quincey Morris wrote:
On Feb 25, 2009, at 05:31, Jerry Krinock wrote:
On 2009 Feb 24, at 20:02, Dave Fernandes wrote:
... I'm only just getting familiar with the idiosyncrasies of
Leopard, however, in Tiger didTurnIntoFault might be called many
times, but awa
Well, now that I've convinced myself that
NSManagedObjectContextObjectsDidChangeNotification does not give
enough information, and that there is no way to reliably maintain a
KVO observer of a managed object, I was going to bite the bullet and
implement custom setters for all the properties
On 2009 Feb 25, at 11:24, Quincey Morris wrote:
I'm not making any absolute assertions here, but this doesn't seem
right to me. If 'awakeFromFetch' isn't called when an object is
faulted in, then transient properties (for example) could never be
worth a damn. I couldn't see anything in the
On Feb 25, 2009, at 05:31, Jerry Krinock wrote:
On 2009 Feb 24, at 20:02, Dave Fernandes wrote:
... I'm only just getting familiar with the idiosyncrasies of
Leopard, however, in Tiger didTurnIntoFault might be called many
times, but awakeFromInsert or awakeFromFetch was only called once
On 2009 Feb 24, at 20:02, Dave Fernandes wrote:
I can't say I have the ideal solution, and I am also using KVO, but
one might want to heed Ben Trumbull's warning before going down this
path...
Complex KVO observer actions need to be carefully constrained. If
they simply grow organicall
14 matches
Mail list logo
