Re: EO model validation with Wonder and foreign keys

Mike Schrag wrote on 12/13/06 5:12 PM:
> So am I correct in stating the rule as: if an EOAttribute is a source 
> attribute of any EOJoin in any relationship in the attribute's parent 
> entity, then it must not be a class property?  Is there actually a 
> justifiable reason for this, or is this a framework bug that PW can 
> maybe fix?

Mike,

As far as I can tell, you have correctly stated the conditions. I don't 
know WOnder well enough to know if it could easily patch the issue.

FWIW, I tried updating the Application, Session and EO classes to 
inherit from the PW hierarchy but I still encountered the issue, so even 
if PW can patch this issue, it doesn't do it yet.

zak.


> On Dec 13, 2006, at 4:55 PM, Chuck Hill wrote:
>>
>> On Dec 13, 2006, at 1:20 PM, Zak Burke wrote:
>>
>>> Zak Burke wrote on 12/12/06 7:32 PM:
>>>> I thought I would bite the bullet and install Wonder, to see if it 
>>>> made all my EO Model/Entity Modeler validation issues magically 
>>>> disappear. I've written about this problem before but was never able 
>>>> to resolve it. Here it is, in a nutshell: When an EO has a required 
>>>> relation, Entity Modeler complains if the EO's foreign key is not 
>>>> also marked as required. EOF, however, chokes when the foreign key 
>>>> is required because it handles validation before a new related 
>>>> object has been persisted, and therefore has no foreign key to assign.
>>>
>>> Well, I managed to solve this.
>>>
>>> The problem only appears if the relationship's foreign key is 
>>> accessible as a class property. If the foreign key is not a class 
>>> property, then apparently EOF never gets access to the property to 
>>> notice that fact that it's empty. That kinda makes sense, but in an 
>>> ostrich-like way. (If I don't look for a value that isn't allowed to 
>>> be empty, it must not be empty! Hooray!)
>>>
>>> I understand how my model caused this to occur, but it seems like the 
>>> model should throw an error whenever a property used as part of a 
>>> relationship is exposed as a class property.
>>>
>>> I know some modeling wonks will flame me about how PKs and FKs 
>>> shouldn't be exposed anyhow and I could have avoided all these 
>>> problems if I had just followed recommendations about what fields to 
>>> expose. IMNSHO, the recommendation ought to be a rule because 
>>> violating it causes an error. At the very least the documentation 
>>> should explain the consequences of ignoring it.
>>>
>>> Ah well; at least now I understand.
>>
>> Then allow me to confuse you.  :-P  I have a large project with the PK 
>> exposed all over the place.  Bad or good, that is the way it is.  It 
>> does not cause problems.  Only exposing the FK seems to cause this 
>> problem.  I do agree that having a validation for this in Entity 
>> Modeler is probably a good thing.
>>
>>
>> Chuck