Belatedly: this is very interesting. I had not considered changing the prototype after it had been set. This makes sense in theory, where at run-time we could set up the model, then change the preferred prototype to reset the model. In practice, this may
amount to a new model. The call sequence is:
[EOEntity -attributes]
[EOAttribute -attributeWithPropertyList: owner:]
[EOAttribute -initWithPropertyList: owner:]
[EOModel -prototypeAttributeNamed:] // to determine the prototype
[EOAttribute -setPrototype:] // sets the prototype
[EOModel -prototypeAttributeNamed:] uses the following order to determine the prototype:
1. [[self entityNamed: @"EOAdapterNamePrototypes"] attributes]
2. [[_group entityNamed: @"EOAdapterNamePrototypes"] attributes]
3. [[_group entityNamed:
@"EOPrototypes"] attributes]
4. [adaptor prototypeAttributes]
In summary, changing the prototype at run-time is not currently supported.
-- 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.
|