Re: sql gen is in

From: Guido Neitzer (guido.neitze..harmaline.de)
Date: Mon Jul 31 2006 - 04:55:18 EDT

  • Next message: Stéphan Mertz: "Entity Modeler"

    On 31.07.2006, at 10:23 Uhr, Anjo Krank wrote:

    > For example, you might want a CONTENT not null field in your Asset
    > entity, which has the name imageData in the Image entity, textData
    > in your Document entity and media in your Media entity. IMO, this
    > is also totally valid, but with this fix in, it would preclude
    > generating the correct SQL. (Which was in fact the reason why the
    > original code did not include child entities of single table mappings)

    Hmm. I can't see, why this shouldn't generate correct SQL as well?!
    I've tested a case I hope fitting your description and the SQL
    generation does this very well. But I might don't get the case correct.

    Again: if only of of your subclasses define this attribute as not
    null in the database, you have to have this in ALL your subclasses.
    So you might also have the specific information in the superclass
    (the "content" attribute which is also not null). Mikes code
    generates valid SQL for that, it defines the db column as not null.

    I don't understand your problem here: if you want to set the "not
    null" constraint only for a single entity, you need to fix the db
    entry. If you want to have the "not null" constraint in the db you
    have to have this attribute (or at least this column) in ALL your
    subclasses as not null, thus you can set it (or a corresponding
    attribute on the same column) to not null in the super entity. This
    works pretty well.

    But if you have a case where you define things in ALL sub entities as
    "not null" but not in the super entity, I'd say your object model is
    broken. But this is my personal view on what I understand from the
    description right now.

    > You may argue that this may be wrong, but my point is that it's no
    > more broken than your model and it would now force *me* to work
    > around this which I can't do easily while you certainly can.

    So you assume your way of doing something is better because you have
    to fix more stuff when correct SQL is generated? Hmm. Not really a
    valid argument.

    > Because I don't think that it's a good idea to create fixes for
    > things that are not broken in the first place.

    If it is not broken - don't fix it. But it IS broken. It generates
    wrong SQL. As far as I understand, you haven't explained a case where
    it is not broken. But I might miss a point because it's really not
    easy to express and / or understand this here.

    > There are a lot of ways to works around this behaviour and neither
    > you nor I have knowledge if this fix doesn't break something else
    > for other people.

    This is the first argument on that topic where I totally agree. I can
    say for myself that I don't have the knowledge of why this is like it
    is and whether there are cases where it actually does any good.

    As far as I understand, you haven't described a case where the fix
    does anything bad for your situation, can you test it? Does ist
    really break anything for you?

    But, perhaps as we all might not have the deep background for
    deciding whether it's good or bad, should we make a compromise? Mike,
    can have this configurable?

    cug



    This archive was generated by hypermail 2.0.0 : Mon Jul 31 2006 - 04:55:21 EDT