Sent from my iPhone > > >> As far as I can tell, this API seems to be one that must have come from the >> desktop version of EOF where you're always in-process to your changes. Those >> API's are all dead to me. > Yes, of course this design is from 'real' EOF! ObjC EOF and AppKit on > NeXTSTEP/OPENSTEP! ;-) > Dead or not, it's the history which forms what we have today. No no I mean api's that presume that you're living in a single instance are dead to me. Clearly i'm a fan of the apis of our ancenstors :)
> >>> This is what I've used in the past (since ObjC days) and I don't know of a >>> case where it fails. >> This depends on your definition of "fail." I agree that for the way you're >> using it it works. For the ACTUAL complaint I have, it seems insufficient. >> I'm also not sure you even run in the right thread to throw that exception. >> This responds to ObjectsChangedInStore, which probably means it runs in >> EC1's thread? Or does it queue up and run in EC2's thread when in >> performRecentChanges or something? Regardless, I suspect to make >> inter-instance and intra-instance behavior match, you're going to have to do >> a lot more work ... hence my gripe. > Those two cases need to be different! If anything, the inter-instance case > is broken in that it doesn't properly notify EC's in other running instances > that objects they are interested in have become invalid! However, until we > have EC's properly hooked into the psychic-friends network, I don't see how > that's going to happen. This is my point though. That problem is close to unsolvable, which means the correct approach from a consistency standpoint would be for same-instance to work like multi-instance. > >> If you can get an optimistic lock on ec2.saveChanges out of this technique, >> I'll be a fan of it (because then we can just wire this into Wonder on all >> EC's and have this problem fixed or at least an opt-in feature), but I'm >> still not convinced yet. > But that's just it, I don't want to have ec2.saveChanges() fail. By the time > that ec2 is back to running, it's EO's have been updated and it's good to > save! No they're merged via some magical merge policy that doesn't involve the user which hid the fact that a locked attribute is being overwritten, negating the entire point of an optimistic locking system as a means of data protection. > The delegate gives the application developer the control to handle this case > in way specific to their application implementation. Something that I could > not divine a general solution too! I see this exactly backwards from you. Optimistic lock failure is this to me. You can catch it and do everything you're describing here (see tolerant ec in wonder) but you can't implement a proper optimistic locking system with the delegate (ok ... It's probably possible ... But clearly non-obvious). Why even have lock attributes if you let a different ec stomp on them. And I still come back to the issue of presenting this conflict to the user, which is most likely what actually has to happen to make this work properly. To do that with the delegate you'd have to do a bunch of tedious work for what should be a relatively rate situation. And you still have to write all your optimistic locking code because it can still happen. So still you're left with two implementations if what is, for all intents and purposes, the exact same problem manifesting in two different api's. > And yes, by the by, I'm pretty sure that you're correct that when the > delegate is called, it's within the thread of the EC which posted the > notification and thus throwing any exception would never make it to the > handler of another EC. Nor should it! ;-) Bah humbug! > Now, having said all that, I would be open to the idea of making this easier > to understand for new developers however that must not come at the cost of > sacrificing the notification that objects have changed from what you thought > they were. M. I have an easy way to make it easier for new developers to understand. Simply make optimistic locking the single way to handle merge conflicts, and add support for core data's merge policy API to provide a default merge policy in the event that you don't want to deal with it per-ec. I'm not in favor of removing that API btw ... I just don't think it adequately addresses the issues I have. I have also decided, after much thought, that even though you are wrong, we can still remain friends. Even with your wrongness. It's a burden I shall have to carry with me ;) What in the world possessed me to take this thread on with the iPhone keyboard? Apologies for crazy words that may appear above. ms
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
