zyx94
zyx94
**您的功能请求与问题有关吗？** 当前仅实现了DB为postgre的版本（有群里询问过是出于postgre的jsonb操作有事务保证），是否可以考虑对其他数据库进行扩展支持。 **描述您想要的解决方案** 看到代码里有预留一个if{}else{}的位置给其他DB存储的实现，但这种方式不够优雅甚至说有点丑陋，建议是可以参考dubbo的插件化思路，将不同DB存储的实现逻辑解耦。 **其他内容**
**您的功能请求与问题有关吗？** 当前服务端按照配置的块大小（比如LuckysheetServer是硬编码成了500*500）将一个sheet划分成一个个块的集合(List)，这个实现有效控制了DB中单行数据的规模，但是也带来一个问题：假设项目起初对于块大小的预估有误，导致后续的迭代中需要修改配置的块大小值，那么已经保存到DB中的数据的blockId值也需要同步进行清洗，否则CRUD会有错误。而通常情况下，已经保存的数据规模是比较大的，对全量的已保存数据进行清洗成本、风险都比较大。 **描述您想要的解决方案** 针对上述问题场景，是否有风险、成本更低的解决思路，而不需要清洗旧数据。 **其他内容** 想到的一种比较直接的思路是新增一个版本属性，它表示当前是使用的哪种块大小配置，后续就算修改了配置的块大小值也能在业务代码层面应对。
**您的功能请求与问题有关吗？** LuckysheetServer对于各端之间通信使用的websocket长链接实现比较简单，只能在试验demo中使用，而且该部分实现与消息的合并代码耦合比较严重，使用者想使用自己的长链接通信实现修改起来比较复杂。 **描述您想要的解决方案** 可不可以将长链接通信部分抽离出来与消息的合并部分隔离开（比如模块化或者插件化），使用者可以很方便的将长链接通信部分替换成自己的实现（比如我们就是使用了自己的消息服务）。 **其他内容** 其他说明
中和下呢？
9102年了，万众期待的中下篇呢
如标题