Flattened relationships - some more analysis

From: Craig Miskell (cmiskel..lbatross.co.nz)
Date: Mon Oct 21 2002 - 17:54:06 EDT

  • Next message: Andrus Adamchik: "Re: Flattened relationships - some more analysis"

    Hi all,
            I'm getting there (slowly) with flattened relationships. Trying
    to fit it in around other things, which makes it slow going at times.

    Anyway, I have found a better way to do the fetching, and will submit it
    shortly. It actually makes selectRelationshipObjects in QueryHelper much
    better (IMHO) - it handles both normal and flattened relationships in
    exactly the same code which is more compact than the original, and uses
    the existing Translator infrastructure to do the joins/foreign-key
    comparisons. It generates "minimal" SQL. Still, that's a side issue.

    What I really wanted to share was my thoughts so far on the automatic
    handling of add/removing from a flattened relationship. 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.

    Sorry if this is long-winded - does it make sense?

    Craig Miskell
    Programmer, Black Albatross, Otago University, New Zealand
    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.1
    GCS d- s+:- a-->? C++++(++)$ ULXH+++$>++++ P+>++++ L++$>++++$ E--- W+++$
    N+ K? w--- !O M-- V? PS--- PE Y t++ 5 X+++ R-- tv+ b+>+++ DI++++ D+ G+ e++
    h--- r+++ y+++
    ------END GEEK CODE BLOCK------



    This archive was generated by hypermail 2.0.0 : Mon Oct 21 2002 - 17:54:18 EDT