Issue 10681: Description not detailed enough (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Clarification Severity: Summary: Problem: The description of the getter, setter and is_xxx_modified operation for attributes of a DLRL object is not detailed enough. An exception listing should be added, and for what type of attributes the exception is valid and under which circumstances. Exceptions for get_<attribute_name> operations: · DCPSError (which should be made a 'runtime' exception, to prevent nasty catch clause needed for each getter!!) o For all (shared) attributes: § a DCPSError if some error happened in DCPS (state might need to be fetched from DCPS, if the object was not dereffed). · NotFound o For mono relation shared attributes: § A NotFound exception if the related attribute could not be located. Exceptions for set_<attribute_name> operations: · PreconditionNotMet o For all (shared) attributes: § Object is not in a (writeable) cacheaccess o For any (shared) attribute that is a key field (predefined mapping only) § Object is already registered (i.e. identity may not be registered anymore) o For mono relation shared attributes: § If the value of the parameter is NIL, but the relation was modeled as a mandatory relation (see XXX) § If the object in the parameter has different keys then the owner object and the relation is mapped using so called 'shared' keys. o For mono/multi relation shared attributes: § 'Owning' object (or owner of the collection if multi relation) is not yet registered. § 'Target' object (or owner of the collection if multi relation) is not yet registered. § If the object (or owner of the collection if multi relation) represented by the parameter has already been deleted (this does not include marked for destruction!) § If the object (or owner of the collection if multi relation) in the parameter is not defined in the scope of the same CacheAccess o For multi relation shared attributes: § If the parameter value is NIL Furthermore the descriptions should also be augmented. The setter description should state that a setter for a collection type basically clears the entire contents of the collection of the 'owner' objects and then copies in the content of the collection in the parameter. Making the setter for a collection work like a clear of the contents of the 'old' collection and then an element for element add of the elements of the other collection. The is_xxx_modified operation description should also state that it takes a ReferenceScope as parameter for (mono/multi) relations. SIMPLE_CONTENT_SCOPE only takes the reference to the related object into account (for multi relations this means elements in the collection, not the multi relation object (pointer) itself which should never change during the life cycle of the owning object!) and REFERENCED_CONTENTS_SCOPE takes the reference to the related object into account as well as the content of the object. Solution: TBD Resolution: Revised Text: Actions taken: February 12, 2007: received issue Discussion: The description for the get_<attribute_name>, set_<attribute_name> and is_<attribute_name>_modified is not detailed enough. End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Feb 2007 15:17:48 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10681 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10681 From: "Erik Hendriks" Description not detailed enough The description for the get_, set_ and is__modified is not detailed enough. Problem: The description of the getter, setter and is_xxx_modified operation for attributes of a DLRL object is not detailed enough. An exception listing should be added, and for what type of attributes the exception is valid and under which circumstances. Exceptions for get_ operations: · DCPSError (which should be made a 'runtime' exception, to prevent nasty catch clause needed for each getter!!) o For all (shared) attributes: § a DCPSError if some error happened in DCPS (state might need to be fetched from DCPS, if the object was not dereffed). · NotFound o For mono relation shared attributes: § A NotFound exception if the related attribute could not be located. Exceptions for set_ operations: · PreconditionNotMet o For all (shared) attributes: § Object is not in a (writeable) cacheaccess o For any (shared) attribute that is a key field (predefined mapping only) § Object is already registered (i.e. identity may not be registered anymore) o For mono relation shared attributes: § If the value of the parameter is NIL, but the relation was modeled as a mandatory relation (see XXX) § If the object in the parameter has different keys then the owner object and the relation is mapped using so called 'shared' keys. o For mono/multi relation shared attributes: § 'Owning' object (or owner of the collection if multi relation) is not yet registered. § 'Target' object (or owner of the collection if multi relation) is not yet registered. § If the object (or owner of the collection if multi relation) represented by the parameter has already been deleted (this does not include marked for destruction!) § If the object (or owner of the collection if multi relation) in the parameter is not defined in the scope of the same CacheAccess o For multi relation shared attributes: § If the parameter value is NIL Furthermore the descriptions should also be augmented. The setter description should state that a setter for a collection type basically clears the entire contents of the collection of the 'owner' objects and then copies in the content of the collection in the parameter. Making the setter for a collection work like a clear of the contents of the 'old' collection and then an element for element add of the elements of the other collection. The is_xxx_modified operation description should also state that it takes a ReferenceScope as parameter for (mono/multi) relations. SIMPLE_CONTENT_SCOPE only takes the reference to the related object into account (for multi relations this means elements in the collection, not the multi relation object (pointer) itself which should never change during the life cycle of the owning object!) and REFERENCED_CONTENTS_SCOPE takes the reference to the related object into account as well as the content of the object. Solution: TBD Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org