I'm late to this debate, and I don't want to dredge up the ugly
arguments that flew by about this, but here's my take. I have run
into the same problem that Guido has. I think Anjo makes a lot of
very good points, but making non-class properties is not always an
option (for my case where I run into this, the superclass is in
another model in a shared framework which can't know about all of its
subclasses or their properties since that is dynamic). It is,
though, convenient to still be able to generate SQL create statements
that are actually valid for my model. However, Anjo is right that it
is a violation of the runtime contract that we have with WO in the
general case -- if you were to generate SQL at runtime, it can't do
this without making the same hacks we make in EOModeler.
To me, this sounds like a candidate for a new checkbox in the SQL
Generator dialog that defaults to NOT be checked. So if you want to
have a runtime-compatible-sql-generating model, you just use the
standard default flags, but if we can make certain workflows in the
UI easier for users of Entity Modeler and if it's not TOO insane, I
say "why not."
How do you guys feel about this compromise? "Convert not-null single-
table inheritance attributes to allows-null?" checkbox, defaulted
off, everybody's happy, and we're all best of friends again?
ms
This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 22:40:04 EDT