Chuck Rolke created QPID-6328:
---------------------------------
Summary: [C++ Messaging] What to do with unsupported data types?
Key: QPID-6328
URL: https://issues.apache.org/jira/browse/QPID-6328
Project: Qpid
Issue Type: Bug
Components: C++ Broker, C++ Client
Affects Versions: 0.30
Reporter: Chuck Rolke
Interoperating with a non-qpid client reveals difficulties handling non-native
data type, such as Amqp 1.0 char (utf32). The following issues are related:
||Issue||Description||
|QPID-6314|Message containing utf32 value is rejected at broker ingress.|
|QPID-6315|Message containing timestamp passes broker ingress but Messaging
client converts timestamp to INT64. Messaging client cannot interoperate using
timestamp data type.|
|QPID-6327|Message containing a map with a utf32 value passes broker ingress
but Messaging client throws decoding the message. Client must use try-catch to
recover from failed message decode. Client cannot access any of the rest of the
map message.|
The difficult data types are
* decimal32
* decimal64
* decimal128
* char
* timestamp
As they have no natural representation in C code.
One possible resolution is to have an external encoding in Messaging that
describes the data. This is identical to the way Messaging handles strings. A
vbin8 string and a utf8 string are both 'string' data type in the customer code
and he needs to use the getEncoding and setEncoding methods to differentiate
them. A possible scheme:
||Native type||Encodings||
|uint32|uint32, utf32, decimal32|
|uint64|uint64, decimal64, timestamp|
This still leaves the decimal128 data type without a representation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
