Hello Mike;
You are dead right -- thanks very much for alerting me to this
problem! I suppose If Apple were to implement a KVO-style
notification "ObjectsWillChangeInStoreNotification" then it would be
easy to implement a relatively safe change notification to take care
of this problem. I can't immediately conceive of any other issues
aside from ordering the changes.
Assuming you had one observer for each object store co-ordinator in
the system or were only concerned with the default object store co-
ordinator then you could cache the pending-update snaps from the
"ObjectsWillChangeInStoreNotification" prior to the change and shift
just the foreign keys over in the queued message.
I wonder if it is worth asking for this additional notification in a
radar item? :-/
cheers.
What you describe here is the first implementation I made for
Project Wonder, actually. It gets really nasty. The problem is
that you have to also watch for updates, because if you change a to-
one relationship, it only results in an update notification. But
objectsChangedInStoreNotification doesn't provide enough
information to respond correctly. By the time it gets to you, the
snapshot cache is already updated, so you have no idea what the
PREVIOUS value was (because that notification only gives you
...
___
Andrew Lindesay
www.lindesay.co.nz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
