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
semantics).
Or we can make a join table explicitly marked as such in the mapping?
Andrus
This archive was generated by hypermail 2.0.0 : Mon Oct 21 2002 - 18:51:07 EDT