Re: refreshObject doesn't seem to work
Re: refreshObject doesn't seem to work
- Subject: Re: refreshObject doesn't seem to work
- From: Ben Trumbull <email@hidden>
- Date: Wed, 8 Oct 2008 20:54:43 -0700
On Oct 8, 2008, at 8:36 PM, Steve Steinitz wrote:
On 8/10/08, Ben Trumbull wrote:
Core Data for a multi-user
How is this configured ? Through distributed notifications
replicating changes, or a network file system mount ? If the later,
is it AFP ?
We're not yet using distributed notifications (and, they're not as
distributed as their name implies :). We use a Thecus network drive
over AFP.
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.
Direct file access via a network mounted file system like NFS or SMB
won't work. There are multiple machine cache coherency issues that
those FS aren't intended to handle at the protocol level. AFP isn't
either, but it simply disables the caching, so slow but correct.
I've 'enhanced' refreshObject
Refreshing either never merges (like rollback) or always merges (like
byPropertyObjectTrump) depending on the flag parameter.
Ah, what I want is byPropertyStoreTrump. I wonder if I could get
refreshObject to behave that way?
Not easily. 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.
If this would be particularly useful, you should file an ER.
1. re-fetch all the relevant managedObjects (arrayController fetch)
2. call the above refreshObject on all of today's sales, every
bike-mold (a sort of bike template) and every bike
That should be enough on its own. In step 1, do you fetch the
related objects as well?
Not systematically over the object graph partly because fetch only
fetches new objects -- it doesn't update existing objects -- and
partly because I questioned the saneness of the approach. 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.
We only generate optimistic locking errors on save, so I'm not sure
what this means.
Sorry, that's just my fuzzy thinking: I also save as part of the
refresh process. Thanks for the useful clarification. (Its a
separate subject but 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. Also, not at all if
someone saves again before you do.
Ben, how would you approach solving this? Do you think
refreshObject's byPropertyObjectTrump vs byPropertyStoreTrump
behavior is relevant?
Try explicitly fetching the other objects you are refreshing. If that
works, then it's worth filing a bug.
- Ben
_______________________________________________
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