On 31.07.2006, at 11:39 Uhr, Anjo Krank wrote:
> again: this *should* not be fixed. It is *your* error and *you*
> should fix this in *your* model. If you think this should be fixed
> your way, post a bug report against EOF and see what the Apple guys
> say to this.
Nope. It's just that it works only for your case.
> BTW, EOM does create the correct SQL for this case:
>
> CREATE TABLE ASSET (OID int4 NOT NULL, CONTENT varchar NOT NULL);
Sure, while the broken SQL generation fits your broken model.
> Sure it is. *I* assume that the way WO handles that internally
> should be consistent with what EM does. The way it is now, it's
> not. When you have your app generate the SQL, your output will be
> different from what it generated when you use EM - which IMO is one
> of the main selling points of the new sql generation.
I partly agree here - but nevertheless: the way WO handles this is
broken. It generates wrong SQL for some cases that are totally valid
from the entity and OO design view.
> The SQL is not broken. You basically lie to EOF, telling it that a)
> your parent entity contains less attributes than it does, and b)
> that they are not-null when in fact they allow null values. And
> then you turn around and say, "oh well, do as I want, not as I say".
No, you just don't understand me.
I don't lie to EOF. I tell EOF that I have an entity where one
attribute is required. But this attribute is not required on the
super entity nor on any other sub entity.
> All you need to do is to add these two fields as non-class
> properties, set the non-null to whatever you think is OK and
> everything works for you and everybody else as it ever did.
No, it does not work! Believe me. If I have any attribute as "not
null" in ANY sub entity, it must be "not null" in ALL entities using
this table and I MUST give a value to the db for that reason.
> And *even* it I fixed this with even more logic in EM, my point is
> that I shouldn't need to, because the way it worked before was
> correct from EOFs view and it's not now.
I absolutely don't agree with that point. EOF and EOModeler are not
consistent in that. You are perfectly allowed to have non null
attributes in any sub entity you like but it doesn't do any cross
check to other entities using the same table.
I totally agree with you, that if ALL your subclasses implement an
attribute on a column that should not be null, it should be set to
not null. With your own argumentation you can also get this now with
having a non null attribute in the super entity for that column.
So, because the broken SQL generation (from my point of view) fits
with your broken model (from my point of view) it should not be fixed
(from your point of view). As I said, we are at a dead end.
It should be fixed from my point of view because I think you assume
that when ONE entitiy in the inheritance hierarchy defines one
attribute on a coiumn as not null, ALL entities in the same
inheritance tree must do the same. For me this is just bad OO design.
If you have something that has not to be null in ALL subclasses, you
have to define this rule in the super class.
> So I'm for pulling this change unless someone actually makes a
> convincing argument that doesn´t involve mind reading.
Cool.
Rule 1: Anjo is always right. Rule 2: If Anjo is not right, see Rule 1.
Anjo, I always accept that you know lots more of WebObjects than I
do, but I can't understand your point in this argumentation. Only
because this case fits your model, you are not able to see that
others may have designs that are as legal and valid as yours but
EOModeler does not generate the correct SQL for them. You assume
without any information from the docs or wherever, that your model is
"right" and all others are "wrong"? You're very self-confident. Show
me ONE LINE IN THE DOCUMENTATION that says, that your or my design is
correct / wrong and I will say no word on that anymore.
We all know that WebObjects and the tools have many bugs and problems
- you should know best as one of the most active WONDER committers.
So only because some behaviour of the tools fits your current design,
you think the tool must be correct? That is absurd.
I'll stop that discussion at this point as I don't see any more need
on discussing that. I CAN fix my problems without a problem, as I
have always done. If others agree with you - fine. If not, fine too.
But I hope, Mike can set a switch to emulate EOModelers (wrong or
right - whatever it is) behaviour so you are happy with it and I'm too.
cug
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 06:30:22 EDT