Core Data - getting externally-created records [was getting fresh records]
Core Data - getting externally-created records [was getting fresh records]
- Subject: Core Data - getting externally-created records [was getting fresh records]
- From: Steve Steinitz <email@hidden>
- Date: Fri, 28 Sep 2007 10:15:14 +1000
Hello Ben,
Thank you for your thoughtful, informative post. I have some comments
and questions.
On Thursday, 27 September 2007 at 1:47 am, Ben Trumbull wrote:
> > 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.
I'm not seeing that result. We are throwing the word 'fetch' around -
here is what I mean:
NSManagedObjectContext *context = [self managedObjectContext];
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
[fetchRequest setEntity: [NSEntityDescription entityForName: @"Sale"
inManagedObjectContext: context]
];
NSError *error = nil;
NSArray *sales = [context executeFetchRequest: fetchRequest
error: &error];
[fetchRequest release];
NSNumber *maxInvoiceNumber =
[sales valueForKeyPath: @"@max.invoiceNumber"];
My experiments indicate that that won't immediately find an
externally-created object unless I precede the above with with
[context reset];
or, as you point out, use a clean context. I may use the clean
context technique as a fall back but I would like to try to get it
working with an existing context.
> 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.
No, that's not an issue right now -- I just want to immediately see
the externally-created object in the least-impacting way.
> 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).
That is interesting, though slightly off the intended topic of this,
admittedly mis-titled, post. But, what does catch my eye is that
looping over the array won't notice a new externally-created object.
Right?
> 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.
Again, slightly off-topic, but let me comment that I have found Core-
Data's merge policies to be highly effective and, so far,
trouble-free. In fact, using the different merge policies I have been
able to give one machine a sort of priority over the others in terms
of its in-memory object graph being holy.
> This problem doesn't affect new objects, since clearly you're not
> using them.
I'm not sure I understand what you are saying there. Do you mean that
because I won't have modified new, externally-created objects, there
won't be merge issues?
> Fetch requests always return new objects.
Then I suppose I need to revisit my experiment -- that is not the
result I (thought I) saw (see above).
> asking the managed object context to -reset is going to do something
> completely different, at a different layer, than working with the
> array controllers.
Yes, obviously [context reset] is extreme and probably undesirable.
But, so far, it is the only way that I have been able to immediately
see a new externally-created object. And regarding the array
controllers, I don't think they have any hope of seeing an
externally-created object without a lot of massaging. Right?
> 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.
Gold - slightly off topic, but gold.
>
> 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.
I confess to being confused by the staleness interval. The more I read
about it, the more confused I am. The more everyone clarifies points
about it, the more confused I am. But, I don't want to discuss it now
-- I will understand it in fine detail at the appropriate time. Once I
have immediate access to externally-created objects, I will turn my
focus to staleness, refresh and merging.
Ben, your observations are helpful and encouraging, thank you. I'm
ready to tackle this problem afresh.
Steve
_______________________________________________
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