Re: multi-instance: orphaned fault
Re: multi-instance: orphaned fault
- Subject: Re: multi-instance: orphaned fault
- From: OC <email@hidden>
- Date: Tue, 20 Jan 2015 15:55:31 +0100
Ken,
On 20. 1. 2015, at 15:37, Ken Anderson <email@hidden> wrote:
> Is there a reason you’re storing the result of the relationship instead of the source? If you stored one level up, you’d properly get a null result instead of a stale fault.
Absolutely -- "If I wrote my code afresh, I could make sure this never happens".
But the problem is that "I've got zillions of legacy Java lines in my project (which might store faults freely, after all, that's what faults are for)".
Thanks,
OC
> On Jan 20, 2015, at 8:01 PM, OC <email@hidden> 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@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden