On 31.07.2006, at 9:34 Uhr, Anjo Krank wrote:
> I see. So the button "Generate SQL" is totally arbitrary and has
> nothing to do with you database?
It has - but it has in the aspect of converting my modeled entities
into SQL tables - and there has to be some intelligence in doing that.
> You are not modeling entities, you are modeling the mapping between
> EOs and your database and as such it's only fair that you give EOF
> a fighting chance so it can know what you actually want. Who knows
> if "Person" is ever instantiated? Who knows what other subclasses
> there are, probably also with a non-null username password, so that
> your constraint *should* be in the DB? You do, and so you should be
> the one to fix this.
I don't think so. EOF knows that an entity will never be instantiated
when it is marked as "abstract". If this mark is not set, it has to
assume that this entity WILL be instantiated during runtime.
And the constraint is not allowed to be in the database when the
superclass doesn't define it. If ALL your subclasses define these
attributes and define them as not null, your inheritance model is
broken.
EOF knows everything it has to know to generate correct SQL. But it
creates things that will never run.
> These are not propagated because the plugins don´t do it. Foreign
> keys *could* get created if the connection dict matched. Both don't
> have anything to do with the issue at hand.
And later you change the connection dictionary and want to handle all
this by hand? Here I think EOModeler is right in not trying to be smart.
Again: I don't think my model is broken - but we are now at a dead
end. You think it's broken, I think it's not. And I found nothing in
the docs to convince me, as I've looked through the documentation for
entity inheritance and found nothing about this particular situation.
Perhaps you have a pointer?
Only "Practical WebObjects" explains the problem and says the
workaround is to remove the constraint in the db. I know that this is
not an argument on the case itself, it's just a solution.
For now, my conclusion is that there is no reason I know of, why a
sub-entity may not introduce a required attribute and why EOModeler
should not be able to generate the correct SQL.
cug
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 03:55:24 EDT