Am 31.07.2006 um 12:30 schrieb Guido Neitzer:
>> 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.
Not if you make it a non-class property, make it not null and then
generate the SQL. I just tried with a recent checkout, the fixed
version of the EOFSQLGenerator jar that doesn't patch the attribute
to allows null and this works with the example I've shown. I have no
idea if you mean if it fails at runtime, but certainly the SQL
generates correctly when I add a non class prop dummy (CONTENT) in
Asset and set this to non-null:
CREATE TABLE ASSET(OID int4 NOT NULL, CONTENT varchar NOT NULL);
or allows null:
CREATE TABLE ASSET(OID int4 NOT NULL, CONTENT varchar );
or have it removed entirely:
CREATE TABLE ASSET(OID int4 NOT NULL, CONTENT varchar NOT NULL);
This works consistently whether Asset is abstract or not. All of
these are correct and it should be easy to test this with your setup.
It it makes problems, than the problem lies elsewhere (plugin,
whatever). As opposed to when you don't remove the fix, where you
just get:
CREATE TABLE ASSET(OID int4 NOT NULL, CONTENT varchar );
whatever you do, which is wrong. I even tried setting MEDIA to allows
null and lo and behold: it makes it allows null.
The only thing is when you extend the model to include this:
have all of them non-null and then generate, you indeed see a
CREATE TABLE ASSET(OID int4 NOT NULL, CONTENT varchar NOT NULL);
which might be what you mean. But you can fix this by adding dummy
(CONTENT, allows null, non class prop):
which generates:
CREATE TABLE ASSET(CONTENT varchar , OID int4 NOT NULL);
as I've been telling you all along.
I don't know why you else see errors but in this small model it just
works like I'd expect it to work. If it doesn´t with your setup, then
you are either doing something else or we're not communicating
correctly. If you mean that it fails at runtime, then it's a bug in
EOF that needs to be addressed elsewhere. But for *generation*
purposes, this fix introduced a bug and one shouldn't need to work
around *this* when isn't needed in the first place.
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.
>> 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.
Which is my point: They *should* be the same. It shouldn't matter if
you were generating your code from your app or in EM (not EOM).
Imagine you want to ship your app as a self-starter, then you want
the SQL you tested with match the SQL you generate at runtime, and
you shouldn't need to fix this later with yet more code.
And the other thing is that *you* can do something to fix this:
- change the allows null of your user/pwd at runtime (which would
actually make sense, as *you* are the one that expects runtime to be
different from generation)
- 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.
or a myriad of other ways, whereas I can't, except edit the SQL for a
bunch of tables of which have no idea what they mean and do. And I
think that people shouldn't need to check their models for a fix that
is not needed in the first place.
> Rule 1: Anjo is always right. Rule 2: If Anjo is not right, see
> Rule 1.
God, this is so cheap.
Actually, rule #1 is "If I'm right, I'm right". So there is no need
for rule #2. Which might hold for you if you were right :)
As this has taken already for to much from all our time, this is the
last mail to this topic. Again, I'll pull the change unless there is
some convincing argument for it.
Cheers, Anjo
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 07:28:07 EDT
