DDS-XTypes 1.2 RTF Avatar
  1. OMG Issue

DDSXTY12 — Key order should be defined using the @Key annotation

  • Key: DDSXTY12-16
  • Legacy Issue Number: 18144
  • Status: closed  
  • Source: ADLINK Advanced Technology Office ( Angelo Corsaro)
  • Summary:

    The X-Types specification had left under-defined mechanism to be used for specifying the order of key attributes.

    The solution adopted by the FTF was to simply use the member ID to define such an order, but this is not optimal.

    We strongly suggest to define @Key annotation as follows:

    @Annotation
    local interface Key

    { attribute unsigned long value; attribute boolean value default true; }

    ;

    Where the value attribute is used to define a total order among the key attributes.

  • Reported: DDS-XTypes 1.1 — Mon, 8 Oct 2012 04:00 GMT
  • Disposition: Closed; No Change — DDS-XTypes 1.2
  • Disposition Summary:

    No change as it could be done as a vendor extension without affecting portability/interoperability

    Ordering of the keys for the purpose of sorting is something that can be handled internally by each vendor since there are no APIs in DDS that specify an order relative to the key order (e.g. the read_next_instance() specifies an order "by instance handle" which is not explicitly mapped to keys).
    In other words, a vendor could add an annotation e.g. @key_order to define the order and use that to optimize how samples are stored in the cache but it would not affect portability or interoperability.

    Making it part of the key definition itself would render types as incompatible as a result of something that seems more like a local optimization of a cache in a specific application which would not affect applications in other nodes.

  • Updated: Thu, 22 Jun 2017 16:42 GMT