• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Solved: refreshObject doesn't seem to work
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solved: refreshObject doesn't seem to work


  • Subject: Re: Solved: refreshObject doesn't seem to work
  • From: Ben Trumbull <email@hidden>
  • Date: Thu, 9 Oct 2008 13:47:10 -0700


On Oct 9, 2008, at 12:54 PM, Nick Zitzmann wrote:


On Oct 9, 2008, at 1:40 PM, Ben Trumbull wrote:

That said, the addition of setRelationshipKeyPathsForPrefetching seemed to help even the SMB setup.

Not surprising. More fetching will reduce the window of opportunity for caching problems. I'm guessing you are mostly impacted by the staleness interval over network FS issue.


I'm having a similar problem as the OP, except that I'm not using a network, just plain ol' HFS+. But I've found that, if I have two applications using the same data store, and one of them adds a record into a mandatory-on-the-one-side one-to-many relationship with another record, then even with calling - refreshObject:mergeChanges: in the other app (where supposedly everything is supposed to revert to being a fault), the relationship between records is not updated unless the relationship is refreshed using -setRelationshipKeyPathsForPrefetching:.

Why is this happening? Why does -refreshObject:mergeChanges: apparently not work on relationships on a local volume?


-refreshObject works on that single object (the receiver), not its related objects. If -setRelationshipKeyPathsForPrefetching: is working around the problem for a local volume, you may need to adjust the staleness interval as you refresh the objects.

The simplest way to think about it is that -refreshObject clears any caching at the NSManagedObjectContext layer and -executeFetchRequest refreshes any caching at the NSPersistentStoreCoordinator layer. - executeFetchRequest always goes to disk (for SQLite) and always populates the PSC's caches with the freshest data. However, Core Data doesn't stomp on managed objects that you might be depending upon, so materialized managed objects (not faults) won't have their data overwritten by fetching.

The staleness interval only affects faulting, at the time of faulting. It will cause fetching if the PSC's caching is too stale. If you temporarily change the staleness interval, you may wish to force firing the fault during the scope of your adjusted staleness interval. You can do that by calling -willAccessValueForKey:nil

If none of that helps you, then a bug report with a test project that demonstrates your problem would be helpful.

- Ben

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Solved: refreshObject doesn't seem to work
      • From: Nick Zitzmann <email@hidden>
References: 
 >Solved: refreshObject doesn't seem to work (From: Steve Steinitz <email@hidden>)
 >Re: Solved: refreshObject doesn't seem to work (From: Ben Trumbull <email@hidden>)
 >Re: Solved: refreshObject doesn't seem to work (From: Nick Zitzmann <email@hidden>)

  • Prev by Date: Re: rolling my own drawer-like child window
  • Next by Date: Re: NSUndoManager messing up Core Data database
  • Previous by thread: Re: Solved: refreshObject doesn't seem to work
  • Next by thread: Re: Solved: refreshObject doesn't seem to work
  • Index(es):
    • Date
    • Thread