Chuck,
On 20. 1. 2015, at 20:19, Chuck Hill <[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.
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 :/
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])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/chill%40gevityinc.com
>
> This email sent to [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]
