Solved: refreshObject doesn't seem to work
Solved: refreshObject doesn't seem to work
- Subject: Solved: refreshObject doesn't seem to work
- From: Steve Steinitz <email@hidden>
- Date: Fri, 10 Oct 2008 01:10:33 +1100
Ben,
Thanks for your consummate help.
On 8/10/08, Ben Trumbull wrote:
Okay, that should work, although due to table level locking
SQLite really only handles a small work group, or a scenario
that is primarily readers.
On busy weekends we only have three machines operating - we
leave the two admin machines off. From the database's point of
view not much happens but bursts of activity before Christmas
might test limits.
... aren't intended to handle at the protocol level. AFP isn't
either, but it simply disables the caching, so slow but correct.
Even so, we've found Core Data's performance to be excellent.
Unbelievable performance, really.
In theory, you could write your own merging, and use
-refreshObject:mergeChanges:NO, but there are a lot of issues with
that. It would be a lot of work, which is why we tell people to just
never invoke -refreshObject:mergeChanges:NO on an object with unsaved
changes. Very hard to get right.
Thanks for the heads up. I think I recently bumped into the
-refreshObject:mergeChanges:NO on an object with unsaved changes
issue in my testing/experimentation -- it wasn't pretty,
generating many exceptions and eventually resulting in a record disappearing.
If this would be particularly useful, you should file an ER.
Based on my small knowledge of the problem, it seems it might be
worth an ER.
I do traverse selected relationships, otherwise I just
[arraycontroller fetch] relevant entities.
This might be your problem. There is a known issue with very small
staleness intervals over network mounts. Try refetching explicitly
all the related objects. -setRelationshipKeyPathsForPrefetching might
be enough, or a couple fetches with IN predicates at worst.
OK, that's gold. I added setRelationshipKeyPathsForPrefetching
to the section over which I traversed for calls to refreshObject
and the results are encouraging. I'm getting fresh data in
cases where I didn't before. More below.
shouldn't calling refreshObject avoid the optimistic locking error on
save?)
Not necessarily when you pass in mergeChanges:YES. A tangentially
related object might trigger the conflict.
OK, that's great information. I haven't seen optimistic locking
errors since sprinkling calls to
setRelationshipKeyPathsForPrefetching. Would that make sense?
Also, not at all if someone saves again before you do.
Ah, of course. And, at present I'm probably over-saving.
Try explicitly fetching the other objects you are refreshing.
If that works, then it's worth filing a bug.
Gold. I'll test further and file a bug if all seems OK.
One thing worth mentioning: although my client uses an AFP
share, it dawned on me that I had recently changed my test rig
to use an SMB share (faster gigabit link). From what you said,
that would have introduced problems. That said, the addition of
setRelationshipKeyPathsForPrefetching seemed to help even the
SMB setup. But now, having reverted to an AFP test rig, I can
NOT make it fail at all.
Thanks again - I need to do more testing but I think I'm out of
the dog house,
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