• 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: CoreData, reset a persistent store
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData, reset a persistent store


  • Subject: Re: CoreData, reset a persistent store
  • From: Pierre Chatelier <email@hidden>
  • Date: Thu, 16 Nov 2006 01:22:34 +0100

If you look at the code, I negated the call (![object isFault]) which means they are fully realized hence your memory consumption.
Yes, we agree on that

These objects either are already in memory or are some how firing on the retrieval
Since they were fetched, yes, they must be in memory; they can be faults (and they are), but the data is cached and firing the fault costs almost nothing.

Fetching takes minimal memory and time, it is the firing of the fetch into a fully realized object that costs the time and memory.
Here we disagree !

My opinion comes from the following documentation : CoreData Programming Guide > Faulting and Uniquing > Realizing a managed object
we can read :


1)If you execute a fetch using executeFetchRequest:error:, this always results in a round trip to the persistent store to fetch the data. The objects returned in the results array are fully realized, and their data is stored in a cache (held by the persistent store coordinator).

my comment : that's what I do : I fetch, and this results in faults- but-realized objects


2)If you fire a fault, Core Data does not go back to the store if the data is available in the cache. With a cache hit, converting a fault into a realized managed object is very fast—it is basically the same as normal instantiation of a managed object. If the data is not available in the cache, Core Data automatically executes a fetch for the fault object; this results in a round trip to the persistent store to fetch the data, and again the data is cached in memory.


my comment : "converting a fault into a realized managed object is very fast", is true in my case since data was fetched and is availabel in the cache.

Regards,

Pierre _______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Reusing HTTP connections
      • From: John Stiles <email@hidden>
    • Re: Re: CoreData, reset a persistent store
      • From: "Shawn Erickson" <email@hidden>
References: 
 >CoreData, reset a persistent store (From: Pierre Chatelier <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Elise van Looij <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Pierre Chatelier <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Elise van Looij <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Elise van Looij <email@hidden>)
 >Re: CoreData, reset a persistent store (From: "Marcus S. Zarra" <email@hidden>)
 >Re: CoreData, reset a persistent store (From: "I. Savant" <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Pierre Chatelier <email@hidden>)
 >Re: CoreData, reset a persistent store (From: "Marcus S. Zarra" <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Pierre Chatelier <email@hidden>)
 >Re: CoreData, reset a persistent store (From: "I. Savant" <email@hidden>)
 >Re: CoreData, reset a persistent store (From: Pierre Chatelier <email@hidden>)

  • Prev by Date: Re: CoreData, reset a persistent store
  • Next by Date: Re: Re: CoreData, reset a persistent store
  • Previous by thread: Re: CoreData, reset a persistent store
  • Next by thread: Re: Re: CoreData, reset a persistent store
  • Index(es):
    • Date
    • Thread