• 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: Core data - getting fresh records
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core data - getting fresh records


  • Subject: Re: Core data - getting fresh records
  • From: Ben Trumbull <email@hidden>
  • Date: Thu, 27 Sep 2007 01:47:21 -0700

My question is, is there any way, short of writing SQL or doing
[managedObjectContext reset], that I can force a Sales fetch to go
directly to the SQLite database and not use the Sales in memory?

Executing a fetch request always goes to the database file on disk. There are several issues about the visibility of new or change objects in successive fetches at the NSManagedObjectContext level.


First, any pending changes you have will be incorporated into the fetch results. So if you've got unsaved deletions or unsaved insertions, those will be merged into the fetch result set. You can use a new, clean context, or -rollback the current context if that's not what you want.

The larger problem is the visibility of changes for objects that preexist in the context when you fetch. Core Data can't know what you're doing with those objects, so it caches the results from the database, but leaves your NSManagedObjects unchanged. You can decide for yourself how to incorporate the latest data in your graph of existing managed objects by calling -refreshObject:mergeChanges: on them after fetching. In a situation where you know the fetch result set is for changes (say you received a notification to that effect) you could just loop over the array and refresh all the fetched objects (but passing a YES flag for any objects that have changes). If you decide not to decide about this problem space, Core Data's merge policies will step in when you try to save changes to objects others have modified underneath you. Since conflicts like that tend to be rare, it's usually more efficient to roll with it than poll frequently for fresh data.

This problem doesn't affect new objects, since clearly you're not using them. Fetch requests always return new objects. This is probably an issue with notifying the array controllers that their content has changed. Asking the controller to -fetch: should work. I don't have any special insights on that beyond what's in the documentation and programming guides. It may be worth another look at that material, as asking the managed object context to -reset is going to do something completely different, at a different layer, than working with the array controllers.

- Ben

p.s.

You should never call -refreshObject:mergeChanges:NO on an object with pending changes. On objects that do not have pending changes, passing the NO flag is much more efficient.

The staleness interval helps establish a limit to how old a cached row can be re-used. It doesn't change the objects you're actively using, but if you refresh them, or pull them into a new context, it will affect them.

_______________________________________________

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:
    • Core Data - getting externally-created records [was getting fresh records]
      • From: Steve Steinitz <email@hidden>
  • Prev by Date: Re: Convenience Methods
  • Next by Date: Re: creating a cocoa nsapp event polling callback
  • Previous by thread: Re: Core data - getting fresh records
  • Next by thread: Core Data - getting externally-created records [was getting fresh records]
  • Index(es):
    • Date
    • Thread