Am 31.07.2006 um 10:55 schrieb Guido Neitzer:
>> For example, you might want a CONTENT not null field in your Asset
>> entity, which has the name imageData in the Image entity, textData
>> in your Document entity and media in your Media entity. IMO, this
>> is also totally valid, but with this fix in, it would preclude
>> generating the correct SQL. (Which was in fact the reason why the
>> original code did not include child entities of single table
>> mappings)
>>
>
> Hmm. I can't see, why this shouldn't generate correct SQL as well?!
> I've tested a case I hope fitting your description and the SQL
> generation does this very well. But I might don't get the case
> correct.
It does not create the correct SQL:
CREATE TABLE ASSET(OID int4 NOT NULL, CONTENT varchar );
whereas it should be not-null. The CONTENT field is not in Asset,
only in Image and Document.
Sure there it a fix for this case too (check all children if the
attribute is in there, then set it not null), but 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.
BTW, EOM does create the correct SQL for this case:
CREATE TABLE ASSET (OID int4 NOT NULL, CONTENT varchar NOT NULL);
>> You may argue that this may be wrong, but my point is that it's no
>> more broken than your model and it would now force *me* to work
>> around this which I can't do easily while you certainly can.
>
> So you assume your way of doing something is better because you
> have to fix more stuff when correct SQL is generated? Hmm. Not
> really a valid argument.
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.
>> Because I don't think that it's a good idea to create fixes for
>> things that are not broken in the first place.
>
> If it is not broken - don't fix it. But it IS broken. It generates
> wrong SQL. As far as I understand, you haven't explained a case
> where it is not broken. But I might miss a point because it's
> really not easy to express and / or understand this here.
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".
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. The way
it is now, it's not and you have no way of knowing what this breaks
for other people because this change is rather subtle to begin with.
>> There are a lot of ways to works around this behaviour and neither
>> you nor I have knowledge if this fix doesn't break something else
>> for other people.
> As far as I understand, you haven't described a case where the fix
> does anything bad for your situation, can you test it? Does ist
> really break anything for you?
I have no idea and I'm not inclined to check (and I shouldn't need
to). David's code has model-generation stuff in that that I haven´t
tried to far, but my educated guess is that the SQL output from the
app will not be the same as the one from EM. 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.
So I'm for pulling this change unless someone actually makes a
convincing argument that doesn´t involve mind reading.
Cheers, Anjo
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 05:39:35 EDT
