Issue 10680: Clarify usage of the is_modified() operation on the ObjectRoot (data-distribution-rtf) Source: PrismTech (Mr. Erik Hendriks, erik.hendriks(at)prismtech.com) Nature: Clarification Severity: Summary: Problem: Firstly all references to primary and secondary (or clone) objects should be replaced with cache and cacheaccess objects respectively. Furthermore the usage of the is_modified operation is unclear, it states that it returns false when the read_state is new. Suppossedly because nothing is modified (it's the first time the data is seen). In that light we can only wonder what the is_modified should return when the DLRL receives a new sample for the underlying topics of the Object, but all the attributes have the exact same value (although the real compare is more complex, as some attributes are actually foreign keys and if a new generation of a relation appeared then the attribute value may not have changed, but the relation represented by the attribute has… but that's more of an implementation issue I suppose), or when a dispose is received, but no new data sample. In those cases should this operation return false, or true? That's not clear from the current description of the operation. Basically we see two options for the is_modified operation 1) true is only returned when one of the is_xxx_modified operations returns true 2) true is only returned if the read_state of the object is something else then NOT_MODIFIED The first operation has some added value, as an application now does not need to access each is_xxx_modified operation and find out nothing has changed. However the drawback is that the read_state may be MODIFIED or DELETED, but the is_modified operation still indicates nothing has changed. Forcing an application to always use the read_state() operation along with the is_modified operation and never being able to just use one or the other to determine if something changed at the object (because an object becoming new or disposed is ussually something an application desires to know). This approach also makes the is_modified operation rather complex, as it's implementation has to evaluate each mono attribute by value, each relation by value AND by reference (by value is needed if it was NotFound before and after an update round, and by reference is needed in case of new generations). This all makes the is_modified operation from a seemingly light weight operation into a heavy weight one. Furthermore if we look at the added benefit of the is_modified operation, it's that we can provide a scope, asking it to check out it's related/contained objects as well for modifications. To us that's the real advantage of this operation over simply getting the read_state of the operation. And that's why we prefer option 2, only returning true if the read_state() is something else then NOT_MODIFIED. Because then an application can simply use the is_modified operation to determine what it wants to do with the object, whether it's new, deleted, modified or one of it's related objects has something modified. That does not matter, one call will tell the application whatever it needs to know, if the application does not require modification info on related objects, then it can just use the read_state or the is_modified with a simple_object_scope. Solution: Replace: o see if the object has been modified by incoming modifications (is_modified). is_modified takes as parameter the scope of the request (i.e., only the object contents, the object and its component objects, the object and all its related objects). In case the object is newly created, this operation returns FALSE; 'incoming modifications' should be understood differently for a primary object and for a clone object. o For a primary object, they refer to incoming updates (i.e., coming from the infrastructure). o For a secondary object (cloned), they refer to the modifications applied to the object by the last CacheAccess::refresh operation. With: o see if the object has been updated in the current update round (is_modified). is_modified takes as parameter the scope of the request, i.e.,only the object contents (SIMPLE_OBJECT_SCOPE), the object contents and its composed objects contents (CONTAINED_OBJECTS_SCOPE, unlimited depth), the object contents, its composed objects contents and all its related (non-composed) objects contents (RELATED_OBJECTS_SCOPE, depth of 1 for related objects and unlimited depth for contained objects). Incoming modifications should be understood differently for a cache object and for a cacheaccess object. o For a cache object, they refer to incoming updates (i.e., coming from the infrastructure). o For a cacheaccess object that is cloned from a cache objects, they refer to the modifications applied to the object by the last CacheAccess::refresh operation. Resolution: Revised Text: Actions taken: February 12, 2007: received issue Discussion: End of Annotations:===== iler: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 12 Feb 2007 15:14:01 -0500 To: issues@omg.org, data-distribution-rtf@omg.org From: Juergen Boldt Subject: issue 10680 -- DDS RTF issue X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org This is issue # 10680 From: "Erik Hendriks" Clarify usage of the is_modified() operation on the ObjectRoot Problem: Firstly all references to primary and secondary (or clone) objects should be replaced with cache and cacheaccess objects respectively. Furthermore the usage of the is_modified operation is unclear, it states that it returns false when the read_state is new. Suppossedly because nothing is modified (it's the first time the data is seen). In that light we can only wonder what the is_modified should return when the DLRL receives a new sample for the underlying topics of the Object, but all the attributes have the exact same value (although the real compare is more complex, as some attributes are actually foreign keys and if a new generation of a relation appeared then the attribute value may not have changed, but the relation represented by the attribute has. but that's more of an implementation issue I suppose), or when a dispose is received, but no new data sample. In those cases should this operation return false, or true? That's not clear from the current description of the operation. Basically we see two options for the is_modified operation 1) true is only returned when one of the is_xxx_modified operations returns true 2) true is only returned if the read_state of the object is something else then NOT_MODIFIED The first operation has some added value, as an application now does not need to access each is_xxx_modified operation and find out nothing has changed. However the drawback is that the read_state may be MODIFIED or DELETED, but the is_modified operation still indicates nothing has changed. Forcing an application to always use the read_state() operation along with the is_modified operation and never being able to just use one or the other to determine if something changed at the object (because an object becoming new or disposed is ussually something an application desires to know). This approach also makes the is_modified operation rather complex, as it's implementation has to evaluate each mono attribute by value, each relation by value AND by reference (by value is needed if it was NotFound before and after an update round, and by reference is needed in case of new generations). This all makes the is_modified operation from a seemingly light weight operation into a heavy weight one. Furthermore if we look at the added benefit of the is_modified operation, it's that we can provide a scope, asking it to check out it's related/contained objects as well for modifications. To us that's the real advantage of this operation over simply getting the read_state of the operation. And that's why we prefer option 2, only returning true if the read_state() is something else then NOT_MODIFIED. Because then an application can simply use the is_modified operation to determine what it wants to do with the object, whether it's new, deleted, modified or one of it's related objects has something modified. That does not matter, one call will tell the application whatever it needs to know, if the application does not require modification info on related objects, then it can just use the read_state or the is_modified with a simple_object_scope. Solution: Replace: o see if the object has been modified by incoming modifications (is_modified). is_modified takes as parameter the scope of the request (i.e., only the object contents, the object and its component objects, the object and all its related objects). In case the object is newly created, this operation returns FALSE; 'incoming modifications' should be understood differently for a primary object and for a clone object. o For a primary object, they refer to incoming updates (i.e., coming from the infrastructure). o For a secondary object (cloned), they refer to the modifications applied to the object by the last CacheAccess::refresh operation. With: o see if the object has been updated in the current update round (is_modified). is_modified takes as parameter the scope of the request, i.e.,only the object contents (SIMPLE_OBJECT_SCOPE), the object contents and its composed objects contents (CONTAINED_OBJECTS_SCOPE, unlimited depth), the object contents, its composed objects contents and all its related (non-composed) objects contents (RELATED_OBJECTS_SCOPE, depth of 1 for related objects and unlimited depth for contained objects). Incoming modifications should be understood differently for a cache object and for a cacheaccess object. o For a cache object, they refer to incoming updates (i.e., coming from the infrastructure). o For a cacheaccess object that is cloned from a cache objects, they refer to the modifications applied to the object by the last CacheAccess::refresh operation. 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