Download RTI Real-Time Connect User`s Manual

Data Representation Mapping
This hierarchical flattening operation of member names may lead to very long column names in
the generated table and can easily exceed the maximum number of characters supported by the
database (some databases limit the column names to 30 characters).
To reduce the length of the generated names, you can instruct Real-Time Connect to consider only
the first n and the last m characters of the flattened name, and eventually resolve any conflict by
using a progressive number between the prefix and the suffix. The two tags
<idl_member_prefix_max_length> and <idl_member_suffix_max_length> (see page 4-18),
defined in the configuration file (described in Section 4.4) and the columns
idl_member_prefix_max_length and idl_member_suffix_max_length in the meta-tables
(described in Section 4.5.1.1.10) tell the daemon the values to use. (The values defined in the
meta-table have precedence over the values defined in the configuration file.)
Suffixes
Suffixes are also needed for column names when multiple IDL primitive types map into the
same SQL type. Because there are more IDL primitive types than SQL primitive types, a full
mapping will result in the use of the same SQL type to hold more than one IDL type. For example, an IDL “long double” has no equivalent in SQL. Thus, a SQL BINARY(16) does double duty
and is used to store both an IDL “long double” as well as an IDL “octet[16]”.
If a “long double” could be treated the same as an “octet[16]” by the Real-Time Connect Daemon,
then there would be no issue and no special name mapping would be needed. However,
because the representation of a “long double” is Endianess-dependent while an “octet[16]” is
not, the Real-Time Connect Daemon must use the column name to decide whether or not a SQL
BINARY(16) value needs to be byte swapped or not when converting to an IDL data type. Since
“long double” has no equivalent SQL type, a “.ld” must be appended to the name of a SQL
BINARY(16) column that is used to store one.
Similarly, a suffix of “.str” is used to indicate that a SQL VARCHAR(x) stores IDL “string”,
which is a NULL-terminated sequence of the primitive type “char”. Without the suffix in the column name, a SQL VARCHAR(x) naturally stores a sequence of chars-the IDL type “sequence
<char,x>.
For the Oracle database, but not the Oracle TimesTen In-Memory database, the IDL “octet”,
“octet[x]” and “sequence<octet,x>” are all stored in the Oracle type RAW. A suffix of “.bin” is
used to distinguish between using RAW to store “octet” and “octet[x]” which can be treated the
same, and “sequence<octet,x>” which must be treated differently by the Real-Time Connect Daemon.
NOTE: Because of the use of suffixes in the mapping of identifiers of certain IDL datatypes, the
identifiers “str”, “ld“, and “bin” are reserved keywords that should not be used as the name of
fields in IDL structures. For example, the following IDL definitions have the same SQL mapping
which would in result in the incorrect treatment of the type “Foo2” by the daemon. Each would
result in a table schema that would have the ten columns named “my_field[0].str”,
“my_field[1].str”, ..., “my_field[2].str”.
struct Foo1 {
string<10> my_field;
};
and
struct Bar {
sequence<char,10> str;
};
struct Foo2 {
struct Bar my_field;
}
5-5