Re: Flattened relationships - some more analysis

From: Andrus Adamchik (
Date: Mon Oct 21 2002 - 18:51:02 EDT

  • Next message: Craig Miskell: "Re: Flattened relationships - some more analysis"

    Craig Miskell writes:

    > Anyway, I have found a better way to do the fetching, and will submit it
    > shortly.

    Cool, I really want to see that :-)

    > Ultimately, we
    > can only really handle the simple case - toMany-> toOne, with the
    > intermediate table being a many-many link table.
    > Any other combination implies that an intermediate table has some other
    > meaning than a link, and therefore cannot be created. E.g.
    > Manager -> Department -> Employees
    > flattened as "myEmployees" say. toDept is a toOne, toEmployees is toMany.
    > Dept cannot be created because it obviously has meaning.
    > Multiple toManys also shouldn't be automatically handled - if, say, the
    > first intermediate table can be handled, then it obviously has no meaning,
    > so it may as well be represented as the second table.
    > Similarly, for any other combination - toOnes other than at the end must
    > represent meaningful objects, toManys other than the first must not and so
    > therefore can be reduced to just the first one in modelling.
    > I do, however, strongly suggest that we implement readonly flattened
    > relationships for all cases where we can't handle add/remove
    > automatically. The above example (myEmployees) is quite valid, and quite
    > useful to read, but writing would be dubious (unless there was a dept
    > already, but we can't assume that unfortunately). Hmmm, perhaps we
    > *could* handle it, throwing an exception if the toOne destination was
    > null? That's getting complex for our initial needs.

    I think this makes sense. Lets limit write cases to:

    T1 -> (m)T2 -> (1)T3

    With T2 being a join table. All other cases should be read only. I guess we
    can make ObjRelationship sniff whether it is read-only or not, and set this
    internal flag. And then throw exceptions if an attempt to modify is made.

    We need something to determine that T2 is a join table. I guess a DbEntity
    that has no ObjEntity is a good candidate (together with relationship

    Or we can make a join table explicitly marked as such in the mapping?


    This archive was generated by hypermail 2.0.0 : Mon Oct 21 2002 - 18:51:07 EDT