Re: GDL2: prototypes and EOAttribute.m

[Mark Clements]

Please see attached for a patch to fix quoting of column names and
Postgresql sequences. I have also included a few formatting changes.

Kindly, Mark.

On 05/21/2017 11:20 PM, Fred Kiefer wrote:
> Hi Mark,
>
> thank you for your patches. I tried to understand the last one before
> integrating it and I am not completely convinced this is the best
> solution. Could you please first provide a few tests that check the
> expected behaviour? That way we could run the test against Apples EOF
> and see if the behaviour there matches the tests and then adjust our
> code to satisfy the tests.
>
> With your latest change we would get values from the first prototype
> even when we set a new one. At least in the case where the first had a
> value and the second hasn't got one. This seems wrong to me.
> Would it be sufficient to remove the line
>
>       _flags.protoOverride = 0;
>
> from setPrototype:?
>
> Fred
>
>
>
> Am 19.05.2017 um 23:35 schrieb Mark Clements:
>> Addendum: -setPrototype:(EOAttribute *)prototype is defined in the API
>> for EOF 4.0 and 4.5. A revised patch is attached which sets
>> _flags.protoOverride and updates the propertyList at the start of
>> -initWithPropertyList:owner. This replaces my patch from yesterday.
>>
>> -- Mark
>>
>> On 05/18/2017 10:50 PM, Mark Clements wrote:
>>> Thanks for accepting my earlier patch on the GDL2 test suite.
>>>
>>> As a reminder, GDL2 has prototypes for different types of attributes:
>>> the prototypes are used to set properties when those properties have not
>>> already been specified for an attribute. The prototypes are specific to
>>> an EOAdaptor. The current issue is that the properties are not being
>>> updated from the prototypes.
>>>
>>> Under the EOAttribute class, -initWithPropertyList:owner calls
>>> -setPrototype early, which sets _flags.protoOverride = 0 and then calls
>>> -_updatePrototype, which carefully manipulates keys based on
>>> _flags.protoOverride -- which has already been set to zero and therefore
>>> does nothing (?). Interestingly, _flags.protoOverride is updated later
>>> in -initWithPropertyList:owner -- but this all happens /after/
>>> -setPrototype has been called with no other effects.
>>>
>>> As most of the remainder of -initWithPropertyList:owner uses
>>> propertyList, one fix would be to update propertyList from the prototype
>>> at -setPrototype. I have attached a draft patch that does this -- but is
>>> this the right approach? Note that this is a more general solution to my
>>> earlier patch. An alternative approach would be to call -setPrototype
>>> late in -initWithPropertyList:owner.
>>>
>>> The patch increased the number of passed tests from 1033 to 1101.
>>>
>>> Kindly, Mark.
>>>
>>> On 05/14/2017 06:22 PM, Fred Kiefer wrote:
>>>> Hi Mark,
>>>>
>>>> thank you very much for this fix on the gdl2 tests. I have applied this
>>>> patch. The only thing I did change was instead of commenting out the
>>>> TEST_EXCEPTION macros I replaced them with the newer PASS_EXCEPTION calls.
>>>>
>>>> Cheers,
>>>> Fred
>>>>
>>>> Am 02.05.2017 um 07:49 schrieb Mark Clements:
>>>>> I have now attached a diff file for these changes.
>>>>>
>>>>> Kindly, Mark.
>>>>>
>>>>> On 05/01/2017 11:25 PM, Mark Clements wrote:
>>>>>> I have had a first attempt at getting the testsuite working with GDL2.
>>>>>>
>>>>>> It seems to have been a while since the GDL2 testsuite was updated (see
>>>>>> patch below). Suggested changes include:
>>>>>>  + Bug fixes on labelling
>>>>>>  + Change -cString to -UTF8String
>>>>>>  + Change sel_eq to sel_isEqual
>>>>>>  + Change #include "../ObjectTesting.h" to #include "ObjectTesting.h"
>>>>>>  + Change ADDITIONAL_NATIVE_LIBS+=EOControl EOAccess  to
>>>>>> ADDITIONAL_NATIVE_LIBS+=EOAccess EOControl (?)
>>>>>>  + Comment out TEST_EXCEPTION: is this still defined?
>>>>>>
>>>>>> This gave me 1031 passed tests, 10 failed sets, 9 failed tests and 5
>>>>>> failed files.
>>>>>>
>>>>>> I was not certain whether the failed tests indicate that the Key Value
>>>>>> Coding mechanism is broken. Any guidance on this point would be welcomed.
>>>>>>
>>>>>> Kindly, Mark.
>

diff-20170605.diff
Description: diff-20170605.diff