Whojohn

# Flink metadata management ## Metadata definition (`StreamPark RoadMap`) ## Step 1 > I will finish to implement the `catalog` function implementation, and source management participates in the design. (Part...

I think Restful is more humanable than grpc. In my mind performanace can improve by mulit instance if we support microservices. (**Not all moudule need microservices**) .

@wolfboys > I can finish kafka datasource which inlclude : json auto infer and so on. - The feature may include: 1. (promise) flink kafka catalog . 2. (promise) json...

# 进度汇报 - 调研实现 1. Flink Sql client 实现：TableEnvironment.getCompletionHints （已经标记为移除，底层基于`calcite complete`实现）。 2. `Zeppline`，`HUE` 实现：前端字符表实现。 3. 自行实现: FST 树 - 性能测试(`FST`树 pk `calcite complete`) 1. `FST` 性能是`Calcite` 10倍。 - 功能性测试 1....

# 第一阶段基本完成了 > 套个 `Spring 请求` 这功能就完事，安排下前端对接，还有提供下`Spring`接口放在哪里，有什么特殊要求没有。 > > 该功能特殊依赖： > > 1. 一个记录词频的文本。 > > > https://github.com/Whojohn/flink-sql/blob/main/statistics ## 1. 为什么要这么实现 **Flink sql Client(TableEnvironment.getCompletionHints 实现)** - 优点 1. 基于`Sql parse`做，可以做到语法检测。...

> 您好，您的 Sql autocomplete 要通过大量的前后端交互来实现吗？对于 B/S 的系统，个人认为这个功能偏前端，前端可以提前加载后台的配置如词典或者元数据，然后具体的提示与补全逻辑可在前端实现，最后通过后台校验语法与逻辑是否可通过。此外在书写的过程中验证和校验的功能其实并不实用，因为不完整的句子一定是无法通过校验的。具体的实现可以参考一下 Dlink 的自定义语法提示与补全与语法和逻辑校验功能。希望此文可以帮助您。 **的确实现前有些考虑不充分，我们的纠错也是基于词而已(现在版本)，之前没了解到`monaco`现在也能做到元解析，所以把这部分完全放后端(还是关键字解析，我们想要元解析)？ 具体没精力调研。假如可以，可以填入，Dlink 的实现吗？一个一个查源码也很累。** 调研结果是：跨节点，比如阿里的`x6`那种交互，语法增强，纠错，特殊屏蔽，涉及到后台的元数据(普通用户不可见元信息，我们内部)都是后端控制的。简单的提示，都走前端。 # 自动补全调研 **调研方向** - 功能性 1. 输入提示： sql 语法提示， udf（系统函数的提示），上下文提示。 2. 输入纠错 - 研发成本 1. 前端开发 vs...