hhuang1231 commented on code in PR #4569:
URL: https://github.com/apache/eventmesh/pull/4569#discussion_r1398420327
##########
eventmesh-openconnect/eventmesh-openconnect-java/src/main/java/org/apache/eventmesh/openconnect/SourceWorker.java:
##########
@@ -233,16 +233,24 @@ private void startConnector() throws Exception {
}
private CloudEvent convertRecordToEvent(ConnectRecord connectRecord) {
+ CloudEventBuilder cloudEventBuilder = CloudEventBuilder.v1();
+
+ cloudEventBuilder.withId(UUID.randomUUID().toString())
+ .withSubject(config.getPubSubConfig().getSubject())
+ .withSource(URI.create("/"))
+ .withDataContentType("application/cloudevents+json")
+ .withType(CLOUD_EVENTS_PROTOCOL_NAME)
+
.withData(Objects.requireNonNull(JsonUtils.toJSONString(connectRecord.getData())).getBytes(StandardCharsets.UTF_8))
+ .withExtension("ttl", 10000);
+
+ for (String key : connectRecord.getExtensions().keySet()) {
+ Object extension = connectRecord.getExtensionObj(key);
+ if (extension instanceof String) {
+ cloudEventBuilder.withExtension(key, extension.toString());
Review Comment:
Note that in the default implementation of
`org.apache.eventmesh.openconnect.offsetmgmt.api.data.DefaultKeyValue`, except
for `Object`, they ultimately store strings.
实际上，在`org.apache.eventmesh.openconnect.offsetmgmt.api.data.DefaultKeyValue`的默认实现中，除了`Object`，它们最终存放的都是字符串。
并且目前的ConnectRecord都是使用`DefaultKeyValue`来保存extentsion的，所以我认为没必要去判断其他类型。
And the current ConnectRecord uses DefaultKeyValue to save extention, so I
think there is no need to judge other types.
I don't know much about the community yet. Does the community intend to
allow users to freely implement `KeyValue` and then allow users to customize
the storage mechanism of `ConnectRecord` internal extension?
我目前对社区还不是特别了解。社区是有打算让用户自由实现`KeyValue`，然后让用户自定义`ConnectRecord`内部extension的存储机制吗？
I'll take your advice if it's really necessary.
如果确实有必要的话，我会接受您的采纳的。
##########
eventmesh-openconnect/eventmesh-openconnect-java/src/main/java/org/apache/eventmesh/openconnect/SourceWorker.java:
##########
@@ -233,16 +233,24 @@ private void startConnector() throws Exception {
}
private CloudEvent convertRecordToEvent(ConnectRecord connectRecord) {
+ CloudEventBuilder cloudEventBuilder = CloudEventBuilder.v1();
+
+ cloudEventBuilder.withId(UUID.randomUUID().toString())
+ .withSubject(config.getPubSubConfig().getSubject())
+ .withSource(URI.create("/"))
+ .withDataContentType("application/cloudevents+json")
+ .withType(CLOUD_EVENTS_PROTOCOL_NAME)
+
.withData(Objects.requireNonNull(JsonUtils.toJSONString(connectRecord.getData())).getBytes(StandardCharsets.UTF_8))
+ .withExtension("ttl", 10000);
+
+ for (String key : connectRecord.getExtensions().keySet()) {
+ Object extension = connectRecord.getExtensionObj(key);
+ if (extension instanceof String) {
+ cloudEventBuilder.withExtension(key, extension.toString());
Review Comment:
Note that in the default implementation of
`org.apache.eventmesh.openconnect.offsetmgmt.api.data.DefaultKeyValue`, except
for `Object`, they ultimately store strings.
实际上，在`org.apache.eventmesh.openconnect.offsetmgmt.api.data.DefaultKeyValue`的默认实现中，除了`Object`，它们最终存放的都是字符串。
并且目前的ConnectRecord都是使用`DefaultKeyValue`来保存extentsion的，所以我认为没必要去判断其他类型。
And the current ConnectRecord uses DefaultKeyValue to save extention, so I
think there is no need to judge other types.
I don't know much about the community yet. Does the community intend to
allow users to freely implement `KeyValue` and then allow users to customize
the storage mechanism of `ConnectRecord` internal extension?
我目前对社区还不是特别了解。社区是有打算让用户自由实现`KeyValue`，然后让用户自定义`ConnectRecord`内部extension的存储机制吗？
I'll take your advice if it's really necessary.
如果确实有必要的话，我会接受您的采纳的。
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
