ngjaying
ngjaying
Thanks for the proposal. How could we use this in the SQL? Do you mean to provide a general plugin which invokes starlark provided as a property or as the...
Need more time to design
@Rory-Z How do you think?
@yongxingMa Could you please take a look?
There is a REST API to show the query plan in runtime https://ekuiper.org/docs/en/latest/operation/restapi/rules.html#get-the-topology-structure-of-a-rule
> As `explain` is supported in most DBMS, I think it worth to be supported in ekuiper too. Maybe I can help. A thousand welcomes
Sure. Currently, we add feature design doc at the LF Edge wiki https://wiki.lfedge.org/display/EKUIPER/Feature+Design+Proposals. You can also add your ideas there.
> @ngjaying > > 例如 : internal/converter/protobuf/fieldConverterSingleton.go:26 这种的就属于protobuf 的专属的 可以放到一个pkg里面。 > > internal/pkg/jwt/jwt_rsa.go:22 这种的 属于 jwt 里面的，也只会这这里用到 ，这种也是可以的。 但是internal/constants.go:51 这种的 Sink ，应该是 全局专属名字，统一定义，方便管理 。 > > 不然容易出现这种潜在的问题，例如 `if "mqtt_source.json" ==...
> 如果 超过三个子包中使用该常量，建议放到internal 中，是否可以呢？ 这个其实没有什么硬性标准，我觉得主要还是看语义。例如，go系统包里很多都有常量，包括 time.MilliSecond 这种，语义上就是time的一部分，所以可以作为包的常量在外部使用。 > 如果定义在包下的话，我建议使用小写开头。其实变量名已经就能够解释语义了，我理解的包可能用来说明项目结构，规划功> 能会好一点。 包的常量如果是内部使用，当然可以小写。大写就是希望外部访问的。Go官方的文档effective go 里，包名还是建议起到语义划分的作用，类似命名空间，可以看看这个文档 https://go.dev/doc/effective_go#package-names，里面的例子 bufio.Reader 和 io.Reader 使用包名区分不同的Reader，而不是全部放在一个包，用名字区分类似internal.bufioReader, internal.ioReader. 有些跟包联系不太紧密的常量，我觉得可以单独提出来。但是，Go里面其实不太建议集中放在一个包里并使用没有语义的包名，比如internal.JSON 这种。
> 对于那个json文件名的拼接的，写个 GenerateJsonFileName 的函数 来把这的文件名返回 ，怎么样？ 也可以的