OK, I finally tracked down the problem, and have found workarounds for the resultant issues.
As previously stated, as part of the migration carried out during a Save As, the awakeFromFetch gets called on all my managed objects. I had a method in one of the managed object classes which was fetching some other objects which included looking at an object that had a two way to-one relationship with the object that was giving all the errors. So it seems that the very act of doing a fetch that fetched an object that was in a to one relationship with this object meant that the object was seen as invalid in some way, and therefore anything that had a relationship back to that object would also be told that it was invalid. It's a bit hard to explain, but I'll try to diagram it - let's say we have entity A which has no direct relationship with anything else. In its awakeFromFetch, it fetches from entity B and through a relationship to C. C has a relationship with D, and D has two way to one relationships with a bunch of other entities. A fetches from B <-> C which has a relationship C <-> D which in turn connects to other entities D <-> various other entities Now for some reason the linkage back from D to C gets marked as invalid, and all the relationships from the various other entities back to D also say that they are invalid because D is invalid. So it appears that I can't fetch across relationships at all during awakeFromFetch. I checked back in the documentation, and there was a suggestion that if you needed to manipulate relationships, you could use performSelector:withObject:afterDelay: to process them. While I'm not actually manipulating relationships, I am fetching across a relationship, so I thought I would try that approach anyway. But when I called my method to query across relationships with a delay, the NSEntityDescription entityForName:inManagedObjectContext: failed, so I checked the context, and found that it was nil. So I checked whether the object was still a fault, and it was, so I called willAccessValueForKey:nil to fire the fault, but then it told me that the object had been invalidated. Therefore, I found no way that I could even get to the entity let alone do anything else. But in this particular case, it was OK for me to move the fetch to the persistent document itself and just call the method after loading, seeing as I don't really have to have it called during a Save As operation. Certainly not the way I would like to have it, but at least it works. So, another week thrown away, trying to track down Core Data's bugs and idiosyncrasies. Sigh. On 02/10/2010, at 3:02 PM, Jerry Krinock wrote: > >> The next thing I'm dreading with Core Data is trying to get autosave to >> work. I got some tips from Ben Trumbull, but it looks like a scary amount of >> work that I don't fully understand...but that's for another day... > > Maybe you've not yet read in the Core Data Programming Guide the hoops that > you need to jump through in order to make "Revert to Saved" work? I'm still > using a close-and-reopen since I couldn't get that to work either. Maybe my > document class rework has fixed it; I should retry Apple's hoops one of these > days, but it's not a priority. > Yes, I gave up on the revert to saved too, and went the close and reopen route. Regards Gideon _______________________________________________ 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
