DDS 1.2 RTF Avatar
  1. OMG Issue

DDS12 — Introduce the concept of cloning contracts consistently in specification

  • Key: DDS12-38
  • Legacy Issue Number: 9520
  • Status: closed  
  • Source: THALES ( Virginie Watine)
  • Summary:

    Summary:

    The specification states that it is possible to clone an Object from the primary Cache into a CacheAccess, together with its related or contained objects for a specified navigatable depth. (We will refer to such an Object tree as a cloning contract from now on). However, while the cloning of objects is done on contract level, the deletion of clones is done on individual object level. What should happen to related objects when the top level object is deleted? Furthermore, it is unclear what the result should be when a relationship from an object A to an object B changes from object A to object C. Should the next refresh of the CacheAccess only refresh the states of objects A and B, or should object C be added and object B be removed from the CacheAccess?

    Proposed Resolution:

    Formally introduce the concept of a cloning contract into the API to replace all other clone-related methods. Cloning contracts are defined on the CacheAccess and are evaluated when the CacheAccess is refreshed.

  • Reported: DDS 1.1 — Mon, 3 Apr 2006 04:00 GMT
  • Disposition: Resolved — DDS 1.2
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:58 GMT