On Wed, 2003-03-05 at 04:36, Andrus Adamchik wrote:
>
> >> this is a reduction in functionality, and knowing my luck, if I made
> >> such a change, it would turn out that someone is doing something nasty
> >> but valid that requires the ability to override the toMany flag on an
> >> ObjRelationship, regardless of the DbRelatoinship underneath.
>
> Database having a "one to many" while object model is "one-to-one" is such
> a scenario. This is a valid and quiet common (though not the best) way of
> handling "master-detail" modeling in the db.
>
> I am not even sure that Cayenne supports it as it is now? Of course there
> is always a workaround for the users to create special getters/setters
> (and we can even handle it like this from in the class generator... if
> ObjRelationship still supports "to-many" notion of course :-)):
>
> setDetail(Detail obj) {
> addToDetailsArray(obj);
> }
You're right, Cayenne doesn't support it right now, and in fact would
throw a CayenneRuntimeException when the data row is turned into an
object [1]. Just to clarify the situation when it would be used: Is
this where although the db would technically allow multiple destination
rows (because the attributes aren't the pk, just an fk back to the
source), but in practice there will only ever be one matching row?
Regardless of whether we support it now, if it's something that should
probably be supported in future, then it kind of scuttles my plan :-(.
I still think it's valid to calculate the nature of the toMany status
for flattened relationships though... unless of course it'd be valid to
flatten across one of these interesting master-detail relationships...
urgh.. Andrus... what are you really saying?
Craig
[1] If the rel is toOne, SnapshotManager.refreshObjectWithSnapshot tries
to use the source attributes of the joins in the first dbrel as an
ObjectId on the target entity. If the underlying dbrel is toMany, then
the call to targetPkSnapshotWithSrcSnapshot will throw the exception.
This archive was generated by hypermail 2.0.0 : Tue Mar 04 2003 - 14:52:04 EST