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