On 2015-01-20, 2:02 PM, "OC" wrote:
Chuck, On 20. 1. 2015, at 20:19, Chuck Hill <[email protected]<mailto:[email protected]>> wrote: I can’t think of a good solution either. This will happen without the synchronizer too, if a different instance deletes it. What would you want to happen? That's the question. I might be missing something, but it seems to me that there's no good general solution for all cases, and the proper solution depends on the particular usage of the stored fault. Which would differ in different pages. Yes, that was exactly my thought. If you wrote it all from scratch, there could be one solution but that is not an option. Most often, I would need to fall back to „behaviour as if the stored fault was null instead“ (which itself might be pretty different in different cases). Sometimes, I would have to inform the user that „the object you were working with has been removed by another user [go to previous/home page]“. Pretty rarely, seems to me, I might do with a generated placeholder instead -- which (I haven't tried, but I believe) is the easiest approach, for I can create the placeholder in DatabaseContextDelegate.databaseContextFailedToFetchObject (which, after all, is precisely what EOF does if I don't implement the delegate method at all :)) At the moment I alas can't see anything easier than checking all objects to which a relationships leads and which can be deleted, and go through code checking whether a result of the relationship may get cached, and check all the places -- which does not look exactly like hour's (or even day's) work :/ And then you still have the problem of different ones needing different handling. A Null Object placeholder might be the best, but I think you would still get odd user behaviour. Chuck Thanks a big lot, OC On 2015-01-20, 6:31 AM, "OC" wrote: Hello there, I've just bumped into a new problem. Unless I am doing something wrong, it does not seem the remote synchronizer helps in this scenario; and I wonder, whether there are some well-known and common tricks to solve it in general? The scenario is quite plain: (a) instance A gets and stores (typically into some sort of cache, but a plain component property suffices[*]) a relationship of some EO for the first time. Thus, it, in fact, gets and stores a fault; (b) instance B updates "some EO" to clean up the relationship and deletes the target object. - the Remote Synchronizer does make sure that "some EO"'s relationship is NULL now in instance A; - nevertheless, it does not do anything at all with the stored fault (c) instance A uses the stored "EO" (which its code essentialy does not know is a fault) -- and oops, it gets DatabaseContextDelegate.databaseContextFailedToFetchObject. (Well one wonders, whether this might be the reason why WebObjects by themselves do not throw when a fault fails, but try to re-construct the object _somehow_) Anyway, to be quite frank, I don't see a decent solution of this problem? If I wrote my code afresh, I could make sure this never happens, but since I've got zillions of legacy Java lines in my project (which might store faults freely, after all, that's what faults are for), I don't see a solution which would ensure my application can't fail and either work improperly or report weird errors to users. Has anybody already found a decent solution of this problem (save for “re-writing all the legacy code”, which, albeit of course optimal, is sort of not manageable any time soon)? Thanks a lot, OC === [*] like with a very plain code -- the real cases are much more complex, but this one suffices to show the problem class MyComponent extends ERXComponent { SomeEOClass stored; public MyComponent(WOContext context) { super(context); stored=someEO.someRelationship(); } public WOComponent nowUseIt() { println "$stored" } } _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]<mailto:[email protected]>) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com This email sent to [email protected]<mailto:[email protected]>
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
