Issue 18144: Key order should be defined using the @Key annotation
Issue 18145: A @Version annotation shall be added
Issue 18146: Improving Extensible Types
Issue 18144: Key order should be defined using the @Key annotation (dds-xtypes-rtf)
Click here for this issue's archive.
Source: PrismTech (Dr. Angelo Corsaro, PhD., angelo.corsaro(at)prismtech.com)
Nature: Enhancement
Severity: Significant
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.
The X-Types specification does not provide any way of attaching version information to topic types. This is unfortunate as this information is quite essential to help debug running systems by identifying which version of the information model each element is working with.
As a consequence a new annotation @Version should be added for topic types. A possible definition of this annotation is shown below:
@Annotation
local interface Version {
attribute unsigned long major;
attribute unsigned long minor;
attribute unsigned long patch_level;
};
Extensible Types do not support monotonic extensions of nested struct types. Adding support for monotonic extensibility of nested structures is straight-forward and requires only a very small change to the existing specification. Our suggestion is to allow for monotonic extensibility at any level in the type structure and accommodate this by serializing a length parameter before any nested structure. No @Id should be serialized since it is likely that user won't specify IDs when using Extensible types and relying on Ids could break the whole scheme.