Am 30.07.2006 um 18:05 schrieb Guido Neitzer:
> On 30.07.2006, at 15:14 Uhr, Anjo Krank wrote:
>
>> This setup is hardly legal for single-table inheritance. Either
>> your table has a non-null or it doesn't. If you want it your way,
>> factor out the fields into some extra table, mark them as "allows
>> null" or fix up the sql yourself.
>
> Why shouldn't this be legal? I'm modeling entities, not tables. And
> an entity might have a non null attribute even when the parent
> entity doesn't know anything about this attribute.
I see. So the button "Generate SQL" is totally arbitrary and has
nothing to do with you database?
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.
> There are a lot of other informations in the model (the entities)
> not propagated to the database like delete rules and foreign key
> constrains through multiple models (the last thing is obvious
> because the other model may point to a different database).
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.
That EOF doesn't choke on your model is just because you don´t
generate SQL with it in your app. If you did, then you would get the
exact same error and rightly so. So again, I'd opt for fixing your
model and make a "show only class properties" option instead. If this
is a common error, then a "auick fix" would be nice but I'm not
really for supporting broken stuff in the first place.
Cheers, Anjo
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 03:35:08 EDT