Okay, last mail on that.
On 31.07.2006, at 13:27 Uhr, Anjo Krank wrote:
> Not if you make it a non-class property, make it not null and then  
> generate the SQL.
I understand your example now. You say, to have that stupid SQL  
generator in EOModeler doing the right thing, I have to have the  
attribute in ALL sub-entities but sometimes as class property and  
sometimes not. Sometimes with "not null" set to true sometimes set to  
false.
Right then: EOModeler creates the correct SQL for this case, but your  
not making any point in saying that is more or less valid than  
anything I had before. What EOModeler should do (and it does for  
other things) is to see that there is a column in one sub-entity that  
is not allowed to be null which doesn't exist in another sub-entity.
With this, you're creating a "fake attribute" in your entity, to tell  
a tool doing the correct thing. In fact, you introduce a design bug  
in your entity with defining attributes at places where they don't  
belong. I really don't know what's better with that than just fixing  
the SQL generation.
The other problem with your argumentation is: With this argument one  
could say, that EVERY column has to be defined in the super entity  
and in the sub-entities you only switch "class property" and/or "not  
null" on or off.
> EOF *is* being clever here and the case in point is that it still  
> works even when you lie to it when you provide it with enough info.
In fact I DO provide enough info.
> - add the non class props to your root entity, set them to allow  
> null. If that somehow doesn't fit your aesthetics, well... this is  
> no reason whatsoever to potentially break stuff for other people.
I can only see that this is another ugly workaround for a thing that  
should "just work" without giving this additional information because  
this information is redundant.
What I can understand is your point in having the SQL generated at  
runtime being the same as the SQL generated by the Modeler. Therefor  
the switch.
cug
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 08:01:19 EDT