Re: More SharedEC woes: relationships into SEC not saved?!?
Re: More SharedEC woes: relationships into SEC not saved?!?
- Subject: Re: More SharedEC woes: relationships into SEC not saved?!?
- From: OCsite via Webobjects-dev <email@hidden>
- Date: Sun, 12 Jan 2020 23:07:55 +0100
Chuck,
> On 12 Jan 2020, at 21:01, Chuck Hill <email@hidden> wrote:
> It only works for code that does _NSUtilities.classForName(). It only works
> for code that defers knowing the class based on a string.
I see, so it is the dictionary approach after all. I somewhat hoped they might
have tweaked the classloader, so that I would be able to patch any class, if
done right.
Do you perhaps happen to have any insight to the original problem?
I thought the EODatabaseOperation might perhaps try to be smart and refuse to
operate over another EC, without realising the another EC in fact is the
current EC's SEC; but I guess in this case it would rather throw an exception
instead of silently ignoring half of the changes :/
Also, I have checked the EODatabaseContext API just in case there might be
either a overridable method to create those database operations, or callable
one to order them, but so far, in vain: all relevant methods seem to be private
(which, far as I understand Java, means they can be called — with some danger
—, but can't be overridden); and the one method whose name seems interesting,
i.e., “NSArray orderAdaptorOperations()”, has no argument, i.e., it does not
seem to be possible to provide my own list of adaptor operations and ask the
DBContext to order them.
Darn.
Well of course I can simply simulate what DBContext most probably does (does it
indeed?), to order adaptor operations using
“compareAdaptorOperation(EOAdaptorOperation other)”; but I somewhat fear there
would be some subtle undocumented difference, which would raise its ugly head
and bite me in tender parts the next month or the next year :/
Thanks and all the best,
OC
>> On Jan 12, 2020, at 7:00 AM, OCsite via Webobjects-dev
>> <email@hidden <mailto:email@hidden>>
>> wrote:
>>
>> P.S.
>>
>>> On 12 Jan 2020, at 14:55, OCsite via Webobjects-dev
>>> <email@hidden <mailto:email@hidden>>
>>> wrote:
>>> As for the fixing... well, I guess I can generate the proper AOs myself,
>>> but the trick is, how do I order them? I would need to reuse the standard
>>> default ordering which EODatabaseContext does normally; but it does not
>>> seem to be accessible anyhow, or am I overlooking something of importance
>>> here?
>>
>> It looks like
>>
>> ERXPatcher.setClassForName(OCSDBOperation,'EODatabaseOperation')
>> ...
>> class OCSDBOperation extends EODatabaseOperation { ... }
>>
>> does not work :( Do I do something wrong, or it simply can't be overridden?
>>
>> To be frank, I do not quite understand how the ERXPatcher (or, rather,
>> _NSUtilities.setClassForName) magic actually works: should it work for any
>> WO/EO class, or is there simply a dictionary somewhere inside the opaque
>> Apple code, and it works only for classes which Apple explicitly addresses
>> by some “Class clazz=dict[name]”, with no way to patch the others?
>>
>> Thanks!
>> OC
>>
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Webobjects-dev mailing list (email@hidden
>> <mailto: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