[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GDL2: prototypes and EOAttribute.m

From: Mark Clements
Subject: Re: GDL2: prototypes and EOAttribute.m
Date: Mon, 5 Jun 2017 19:59:34 +0000

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]