sunxiaojian commented on PR #247: URL: https://github.com/apache/rocketmq-connect/pull/247#issuecomment-1214971620
> 我提交该pr的之前看过debezium的kafka connect adaptor，有以下几点我还是想提交一个通用的灵活的适配器： （1）debezium的kafka connect adaptor专注于debezium的适配，缺少通过kafka插件组件来提供通用和灵活 （2）直接适配其他的kafka connector可能还有其他地方没有考虑到，比如source connector的位点序列再反序列化的类型丢失,如Long序列化再反序列化变为Integer。 （3）debezium的kafka connect adaptor为了和其他rokectmq原生connector和插件交互，scheme之间做个映射。 但 我想的是大多数用户使用一个通用的适配器都是kafka source connector和kafka sink connector配对使用的，很少会和rokectmq原生connector和其他插件混合使用，这不但引入开销而且必须保证scheme能做到一一映射，可能会后期升级有影响。 > > 关于scheme和transforms适配，我想的是通过在rokectmq connect的transforms层面去做，这样用户觉得必要的时候（比如和rokectmq原生connector和其插件配合的时候）才去做这个配置。 通用性比较认同，这个也是计划要去支持； 丢失类型问题这个好像不存在，source 的 offset 无论是rocketmq 还是kafka 定义的都是 object类型，不是固定类型，所以在返回offset不会直接拿固定类型，具体什么类型的是有包含业务逻辑的插件内部来决定的， 这个是在转换过程中遇到问题了吗？ 关于升级问题，应该是个逃不开的问题，无论是运行在 rocketmq 上面的 kafka connect，还是直接运行在kafka 上的kafka connect 都面临这个问题，还是但是好在都是api层面的变更，不会非常频繁；并且保证api变更时项目修改最小就可以了， 其实无论在transform层面做schema转换还是直接转换逻辑应该差别不大，在做transform 转换时可以考虑是否把debezium的 adaptor 中 schema的转换直接提成transform就可以了 -- 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]
