On Apr 20, 2010, at 11:22 AM, olivier destrebecq wrote: > Just to clarify, when i say save, i mean call save: on the context and write > it to disk. Which the documentation state that you don't have to call save: > to be able to query for objects and that modified object will be found.
Yes. Everything the person said in their email was entirely false (even the statement about SQL). Ignore it completely. > If i wait a little bit (probably for the next event in the event loop) then > the object is found and i never called save: on the context (which will save > the context to disk). I actually only call save: when the app exits. > > The save: method will commit to disk, i'll looking for what trigger a commit > to context I guess. All the save: does is flush all changes to the context to the persistent store. Therefore, they must already be "committed" to the context, so to speak. Assuming that you have only one context and are not using multiple threads, you may be running into an issue where you have to call -processPendingChanges on the context. This might be why you see the delay in "committing", as processPendingChanges is normally called in the run loop. Give that a shot. > I think what i'm running into is this: > "If you fetch some objects, work with them, and then execute a new fetch > that includes a superset of those objects, you do not get new > instances or*update data for the existing objects > *—you get the existing objects with their current in-memory state." > > The question is how do i commit the updated data to the in memory > representation? Just to clarify that statement, the docs are simply saying that, no matter what, you will always get the in-memory representation, and in fact, will get the very same manage object that you have previously edited, rather than a new object with updated values. > On Tue, Apr 20, 2010 at 9:23 AM, Joanna Carter < > cocoa...@carterconsulting.org.uk> wrote: > >> Hi Olivier >> >>> I create an object and insert it into the context, then i update a couple >>> properties. >>> >>> Later I i do a fetch request with a predicate on the property i updated >>> after the insertion. If i do this fetch right after the update of the >>> property (using the accessors provided by coreData), then the fetch does >> not >>> find the object I created. If i wait longer then it finds it. >>> >>> Is there a way to "commit" the change so that the fetch will find the >> object >>> without saving. I don't want to save every time i update a property. >> >> Since a fetch request returns fully saved objects, I can't see how you can >> expect it to see unsaved changes. >> >> Think about it in database terms - you wouldn't expect a SQL statement to >> return anything other than committed rows. Essentially Core Data is an "OO >> database" and, unless you write your own caching, I doubt if you are going >> to get what you want without saving. >> >> Joanna >> >> -- >> Joanna Carter >> Carter Consulting >> >> > _______________________________________________ > > 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/cocoa-dev%40esoteritech.com > > This email sent to cocoa-...@esoteritech.com > Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ 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
