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 documentation that
*explicitly* says that 'awakeFromFetch' is called in these
circumstances, but nothing else makes any sense.
To confirm the breaking of the observer after delete and undo which I
saw in my app, I did a quick experiment with DepartmentAndEmployees .
I added NSLogs to -awakeFromInsert, -awakeFromFetch and -
didTurnIntoFault. [1]
TEST #1 Using a Newly-Inserted Object
Click the "Add" button to add an Employee...
12:09:35 -[Employee awakeFromInsert]
Click the "Add" button on the sheet, to, I guess, set attributes:
12:09:46 -[Employee awakeFromInsert]
12:09:46 -[Employee didTurnIntoFault]
Select the new Employee and click "Remove"...
Employee disappears from GUI and...
12:09:56 -[Employee didTurnIntoFault]
Click Edit > Undo. Employee reappears in GUI, but...
<Nothing logged>
You see, there is no -awakeFromAnything when it reappears and, we
presume, "faulted back in" as you say. Further, had I had added an
observer in -awakeFromInsert and removed an observer in -
didTurnIntoFault, although I now have an Employee alive in the GUI the
number of its observers is +1 +1 -1 -1 = 0. No good!
I then performed another test, saving, closing and re-opening the
document to see how it worked with a fetch. The document closed OK,
again with +1+1-1-1=0 observers, and executed an -awakeFromFetch upon
reopening. So far, so good. One Employee, one observer. Then I
deleted the Employee, but I did not get -didTurnIntoFault. Then I
undoed to bring it back, and again no -awakeFromFetch, but this is
because for some implementation-dependent reason it did not fault when
I deleted it.
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, or perhaps it's a
current implementation detail that can't be relied on in the future.
Agreed. As I have just shown, faulting occurs with a newly-inserted
object but not one that was fetched from the persistent store.
Further, I wouldn't expect 'awakeFromFetch' to be called as a result
of undo. I might expect 'awakeFromInsert' to be called as a result
of undoing a deletion, but, given Core Data undo's overall
inscrutability, it's possible that it just restores the previous MOC
state directly,
Indeed, that is what I see.
without invoking the various supporting "notification" methods.
Well, from prior experience I'm pretty sure that, for example,
NSManagedObjectContextObjectsDidChangeNotification is invoked.
(Undo does, for example, restore the values of transient properties,
so *that* reason for needing some kind of 'awakeFrom...' is obviated.)
Yes, so that explains your paradox you raised initially.
So, my conclusion is that Dave is correct and that my Class Observers
idea is no good because performing Delete and Undo causes an object to
lose its observer and not get it back.
Jerry
[1] Replace the -awakeFromInsert at Employee.m:35 with this code:
- (void)awakeFromInsert
{
NSLog(@"%s", __PRETTY_FUNCTION__) ;
static int tempID = 1;
[self setValue:[NSNumber numberWithInt:tempID++]
forKey:@"employeeID"];
}
- (void)awakeFromFetch
{
NSLog(@"%s", __PRETTY_FUNCTION__) ;
[super awakeFromFetch] ;
}
- (void)didTurnIntoFault
{
NSLog(@"%s", __PRETTY_FUNCTION__) ;
[super didTurnIntoFault] ;
}
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
