Re: sql gen is in

From: Guido Neitzer (guido.neitze..harmaline.de)
Date: Mon Jul 31 2006 - 08:01:15 EDT

  • Next message: Mike Schrag: "Re: Entity Modeler"

    Okay, last mail on that.

    On 31.07.2006, at 13:27 Uhr, Anjo Krank wrote:

    > Not if you make it a non-class property, make it not null and then
    > generate the SQL.

    I understand your example now. You say, to have that stupid SQL
    generator in EOModeler doing the right thing, I have to have the
    attribute in ALL sub-entities but sometimes as class property and
    sometimes not. Sometimes with "not null" set to true sometimes set to
    false.

    Right then: EOModeler creates the correct SQL for this case, but your
    not making any point in saying that is more or less valid than
    anything I had before. What EOModeler should do (and it does for
    other things) is to see that there is a column in one sub-entity that
    is not allowed to be null which doesn't exist in another sub-entity.

    With this, you're creating a "fake attribute" in your entity, to tell
    a tool doing the correct thing. In fact, you introduce a design bug
    in your entity with defining attributes at places where they don't
    belong. I really don't know what's better with that than just fixing
    the SQL generation.

    The other problem with your argumentation is: With this argument one
    could say, that EVERY column has to be defined in the super entity
    and in the sub-entities you only switch "class property" and/or "not
    null" on or off.

    > 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.

    In fact I DO provide enough info.

    > - 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.

    I can only see that this is another ugly workaround for a thing that
    should "just work" without giving this additional information because
    this information is redundant.

    What I can understand is your point in having the SQL generated at
    runtime being the same as the SQL generated by the Modeler. Therefor
    the switch.

    cug



    This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 08:01:19 EDT