The message is parsed into a string and then converted into a JsonObject, which is used as the basic data structure for subsequent operators processing.
Disadvantages of present design:
Converting a body into a String will restrict the use scenarios and will also be incompatible with the RocketMQ Schema. After client using RocketMQ Schema, not all bodies can be directly converted into a String or JSON, for example, some messages are serialized in Avro format.
At present, when using rocketmq-streams, operations in the form of Java objects are not supported. Operators such as map, flatMap and filter need to explicitly convert into JsonObject, which is very unfriendly.
In RsqlDB, the body format of each message is required to correspond to the Table structure strictly according to the field order and separated by commas, as follows. This invisible requirement is very unfriendly.
All types of bodies can be converted into JsonObject or UserDefinedMessage according to the RocketMQ Schema, and subsequent window operators still use JsonObject as the basic data structure. Scenarios are supported where schema registry components are not deployed.
The message content for rsqldb can be based on the serialization of Java objects, rather than the comma separated format of strictly ordered field values.
Subsequent window operators can be processed based on Java objects, rather than JsonObject. But this will take a long time and hard work, since the overall link relies heavily on JsonObject at present.
The present situation of RocketMQSource:
The message is parsed into a string and then converted into a JsonObject, which is used as the basic data structure for subsequent operators processing.
Disadvantages of present design:
Converting a body into a String will restrict the use scenarios and will also be incompatible with the RocketMQ Schema. After client using RocketMQ Schema, not all bodies can be directly converted into a String or JSON, for example, some messages are serialized in Avro format.
At present, when using rocketmq-streams, operations in the form of Java objects are not supported. Operators such as map, flatMap and filter need to explicitly convert into JsonObject, which is very unfriendly.
In RsqlDB, the body format of each message is required to correspond to the Table structure strictly according to the field order and separated by commas, as follows. This invisible requirement is very unfriendly.
Steps to complete this issue
All types of bodies can be converted into JsonObject or UserDefinedMessage according to the RocketMQ Schema, and subsequent window operators still use JsonObject as the basic data structure. Scenarios are supported where schema registry components are not deployed.
The message content for rsqldb can be based on the serialization of Java objects, rather than the comma separated format of strictly ordered field values.
Subsequent window operators can be processed based on Java objects, rather than JsonObject. But this will take a long time and hard work, since the overall link relies heavily on JsonObject at present.