Issue 10545: DLRL Issue: Need clarification on limitations of bi-directional association (data-distribution-rtf) Source: OCI (Mr. Donald Busch, busch_d(at)ociweb.com) Nature: Uncategorized Issue Severity: Summary: Bi-directional associations involving multi-relations (either 1-to-N or M-to-N) and underspecified. Modifications to one side of a bi-directional relationship is supposed to be automatically reflected in the other side of the relationship, (see 3.1.3.2.2) but that is not always possible given the provided Collection interfaces. The behavior is clear if one of the multi-relations involved is a Set. A change one side of the association causes an add/remove on the Set side of the association. The behavior is interpretable if one of the multi-relations involved is a List. In a UML 1-to-N or M-to-N relationship, is is expected that there will not be duplicate entries in the "multi" side of the relationship. In other words, in a Foo<->*Bar relationship, the same Bar will not occur more than once in the Foo's list of Bars. Using this interpretation, you can interpret a n "add" to the non-List side of the relationship as implying that a new object is added to the end of the list, and a "remove" as implying that the object is removed from the List. In other words, we can treat the List just like a Set and allow changes to the association from both sides. The caveat is that you can't have duplicate entries in a List that is involved in a bi-directional association. (Then again, what if you modify the association from the List side, and you put duplicate values? Do we allow that?) Bi-directional assoications get very tricky when IntMaps or StrMaps are involved. If two maps are involved (e.g. IntMap to StrMap), then it is impossible to modify the association. If I add to it from the IntMap side, then I have to somehow specify the key to use on the StrMap side. The Collection interfaces provide no mechanism to to this. If only one map is involved (either 1-to-N or M-to-N), then I must to all modifications from the map side. Otherwise, I have no way to indicate the Map key when I modify the association. So, the specification need to be clarified on bi-directional associations: 1. The behavior of a List in a bi-directional association must be clarified. Is what I said above correct, or should there be limitations on how you can use a List in a bi-directional association? 2. The usage of IntMaps and StrMaps must be clarified. There are several possibilities: a. IntMaps and StrMaps are not allowed in bi-directional associations b. IntMaps and StrMaps are allowed, but you must make all modifications to the association from the Map side of the association. Map-to-Map associations are not allowed. c. All types of associations are allowed, and the OMG will add to the Collection API to provide the methods needed to set the map keys appropriately from either direction Resolution: Revised Text: Actions taken: December 22, 2006: received issue Discussion: End of Annotations:===== il-OSG: osrJ3_AVM1kvZWN7SWWuWrDWYtsxhwIlDklflzGg8lVhjFK2Ng0ru0hKQu6D7PF052uz6LvUwiOcHJ4Q650qRHyFeqZAa1T18tUpAsAzMpau.fuQIcf_1rgM_KrO8Gu3gQi8EnNU8EUis4XIIr6KSuwdX6JZHeIQJ8LrkooDsZgw9bCb03EC.gfjsdAp Date: Fri, 22 Dec 2006 16:38:11 -0600 From: Don Busch User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: issues@omg.org Subject: DDS 06-04-09, DLRL Issue: Need clarification on limitations of bi-directional associations Bi-directional associations involving multi-relations (either 1-to-N or M-to-N) and underspecified. Modifications to one side of a bi-directional relationship is supposed to be automatically reflected in the other side of the relationship, (see 3.1.3.2.2) but that is not always possible given the provided Collection interfaces. The behavior is clear if one of the multi-relations involved is a Set. A change one side of the association causes an add/remove on the Set side of the association. The behavior is interpretable if one of the multi-relations involved is a List. In a UML 1-to-N or M-to-N relationship, is is expected that there will not be duplicate entries in the "multi" side of the relationship. In other words, in a Foo<->*Bar relationship, the same Bar will not occur more than once in the Foo's list of Bars. Using this interpretation, you can interpret a n "add" to the non-List side of the relationship as implying that a new object is added to the end of the list, and a "remove" as implying that the object is removed from the List. In other words, we can treat the List just like a Set and allow changes to the association from both sides. The caveat is that you can't have duplicate entries in a List that is involved in a bi-directional association. (Then again, what if you modify the association from the List side, and you put duplicate values? Do we allow that?) Bi-directional assoications get very tricky when IntMaps or StrMaps are involved. If two maps are involved (e.g. IntMap to StrMap), then it is impossible to modify the association. If I add to it from the IntMap side, then I have to somehow specify the key to use on the StrMap side. The Collection interfaces provide no mechanism to to this. If only one map is involved (either 1-to-N or M-to-N), then I must to all modifications from the map side. Otherwise, I have no way to indicate the Map key when I modify the association. So, the specification need to be clarified on bi-directional associations: 1. The behavior of a List in a bi-directional association must be clarified. Is what I said above correct, or should there be limitations on how you can use a List in a bi-directional association? 2. The usage of IntMaps and StrMaps must be clarified. There are several possibilities: a. IntMaps and StrMaps are not allowed in bi-directional associations b. IntMaps and StrMaps are allowed, but you must make all modifications to the association from the Map side of the association. Map-to-Map associations are not allowed. c. All types of associations are allowed, and the OMG will add to the Collection API to provide the methods needed to set the map keys appropriately from either direction. -Don Busch -- ---------------------------------------------------------------- Don Busch, Principal Software Engineer and Partner Object Computing, Inc. (OCI) http://www.ociweb.com http://www.theaceorb.com http://jacorb.ociweb.com "Never let what you can't do get in the way of what you can do." - John Wooden X-YMail-OSG: pZkynF0VM1mjeL5xaL.LlLJ.0bFkJxq_PxsoINj5QeEQ5pDXUjM8kUrG1oZOrnjDNKiw16vrimz1Fi1i4wUYY7frbCCBPk02A2aSvwrd8oOgN0UOShuXRvqpQuJHiW2sXmL4p2V9RS584UY- Date: Wed, 09 May 2007 13:19:21 -0500 From: Don Busch User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) To: data-distribution-rtf@omg.org Subject: [Issue 10545] Suggest we add the following text (or something like it, if this is not correct) In Section 8.1.3.2.2: The limitations of a one-to-many association are as follows: o If a List, IntMap, or StrMap is the "many" side of the association, then the association may only be modified from its "many" side. In other words, only the List, IntMap, or StrMap may be directly updated by the application code. (Unless we do a search by value in the List/IntMap/StrMap, and eliminate all of the entries with that value? Is that what's intended? In the List case, won't that leave holes in the List?) o If a Set is the "many" side of the association, then the association may be directly modified from either the one or the many side. The limitations of a many-to-many associaton are as follows: o If one side of the association is a List, IntMap, or StrMap, then the other side must be a Set, and the application may only modify the association from the List/IntMap/StrMap side. In other words, the application may not directly modify the Set. (Unless we do a search by value in the List/IntMap/StrMap, and eliminate all of the entries with that value? Is that what's intended? In the List case, won't that leave holes in the List?) o If both ends of the association are Sets, then the application may directly modify either end. -- ---------------------------------------------------------------- Don Busch, Principal Software Engineer and Partner Object Computing, Inc. (OCI) http://www.ociweb.com http://www.theaceorb.com http://jacorb.ociweb.com "Never let what you can't do get in the way of what you can do." - John Wooden ---------------------------------------------------------------- ----------------------------------------------------------------