> > 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).
I think it can be identified by being a dbEntity whose attributes are
entirely the foreign keys of the joins. Any additional attributes (even
"allowed empty") invalidate writeability. I'm not so sure about
checking for the lack of an ObjEntity... seems a little difficult (given
that there's no immediate way to ask a DbEntity for any ObjEntities that
use it) for not much advantage. If the user really wants an ObjEntity,
I say let them :-)
>
> Or we can make a join table explicitly marked as such in the mapping?
I think we can infer it along the way... it is the destination of the
first relationship, and needs the pk of the source and the destination
to make up it's own pk/attribute list.
Will get back to you when I've gotten a little further,
Craig
This archive was generated by hypermail 2.0.0 : Mon Oct 21 2002 - 19:02:31 EDT