达梦数据库适配

[qw4285632q]

通过Jules 自动编写代码，进行线下调试和生产环境测试。目前已实现达梦数据库的sql上线、查询、备份、sql检测、sql回滚和自动备份功能。sql脚本新增dm.sql 进行备份表的创建。后续将增加tidb 、sqlserver的备份功能。全部采用新的备份逻辑即更新和删除前，将原数据按行解析到sql_backup_history表中。避免因各数据的不同导致的备份逻辑区别

[LeoQuote]

达梦和mysql 和oracle 都可以兼容，你新做的模块新增了什么功能吗？

[qw4285632q]

达梦和mysql 和oracle 都可以兼容，你新做的模块新增了什么功能吗？

archery什么时候对达梦数据库进行了支持。我没看到官方文档有此功能介绍呀 。当初提issue的时候 得到的回复是得自己开发呀

[LeoQuote]

不好意思, 我可能回复的太武断了, 我认知里, 达梦是支持使用 mysqlclient 进行连接的, 我也不太清楚这个认知是否正确, 我这个认知是否有一定的误区?

如果我说错了欢迎指正.

如果达梦支持使用 mysqlclient 进行连接, 那么直接使用 mysql engine 即可.

如果达梦仅支持达梦自己的sdk 进行连接, 那么非常欢迎你的 PR.

另外PR 当前有一个问题, 就是将备份功能优化和达梦数据库 支持混在了一起, 我个人认为, 达梦数据库支持是一个相对常规的 pr, 这个 pr 我想接受起来会比较简单, 推荐你简化一下当前 PR, 仅包括达梦数据库支持的相关工作, 也就是 engine 的相关实现和前端的小修改.

另一个功能 备份功能优化 也是相当实用的一个功能, 但是不可否认他和旧备份流程比较, 是有较大的差异的, 所以我推荐你将其分开提交, 我们可以详细探讨.

另外, 我非常不推荐关闭当前的 pr 并重开完全相同的 pr, 我推荐你继续在此分支上进行推送, 如果新开 pr, 由于讨论不连贯, 会导致审阅变得不方便, 希望你能配合.

[qw4285632q]

不好意思, 我可能回复的太武断了, 我认知里, 达梦是支持使用 mysqlclient 进行连接的, 我也不太清楚这个认知是否正确, 我这个认知是否有一定的误区?

如果我说错了欢迎指正.

如果达梦支持使用 mysqlclient 进行连接, 那么直接使用 mysql engine 即可.

如果达梦仅支持达梦自己的sdk 进行连接, 那么非常欢迎你的 PR.

另外PR 当前有一个问题, 就是将备份功能优化和达梦数据库 支持混在了一起, 我个人认为, 达梦数据库支持是一个相对常规的 pr, 这个 pr 我想接受起来会比较简单, 推荐你简化一下当前 PR, 仅包括达梦数据库支持的相关工作, 也就是 engine 的相关实现和前端的小修改.

另一个功能 备份功能优化 也是相当实用的一个功能, 但是不可否认他和旧备份流程比较, 是有较大的差异的, 所以我推荐你将其分开提交, 我们可以详细探讨.

另外, 我非常不推荐关闭当前的 pr 并重开完全相同的 pr, 我推荐你继续在此分支上进行推送, 如果新开 pr, 由于讨论不连贯, 会导致审阅变得不方便, 希望你能配合.

达梦数据库模式级别支持设置参数兼容oracle或者mysql级别。只能选择兼容一种，而且只是在语句语法层面。但是连接协议层面并非像tidb那样直接使用mysql协议连接。导致审核平台无法兼容达梦数据库 备份功能是因为原先的mysql的备份方式受限条件颇多同时也使用了goinception的部分功能，这导致就算是tidb也无法正常使用备份功能。因此这边采用了一种比较通用的备份方式，即先查询直接备份。但是对于原先mysql的备份逻辑没有修改。这样可以后续将sqlserver、tidb全部支持备份功能，因为这些也是我们这边在使用的数据库。 后续新的更新我也尽可能在此pr推送。

[LeoQuote]

你当前的备份逻辑还是有一些值得探讨的地方的, 我还是比较建议你将其抽离出来单独提交, 比如你当前的设计, 备份的回滚语句是用 json 方式存储在数据库中的, 那么这个数据是否会太大? 是否会有效率问题? 这都需要再探讨一下, 如果我们两个功能一起来讨论, 势必会增大复杂性, 并且拖延你达梦数据库适配的进度.

[qw4285632q]

你当前的备份逻辑还是有一些值得探讨的地方的, 我还是比较建议你将其抽离出来单独提交, 比如你当前的设计, 备份的回滚语句是用 json 方式存储在数据库中的, 那么这个数据是否会太大? 是否会有效率问题? 这都需要再探讨一下, 如果我们两个功能一起来讨论, 势必会增大复杂性, 并且拖延你达梦数据库适配的进度.

其实当前的备份逻辑也仅仅影响到达梦数据库，并非侵入到其他数据类型的代码。而且关于备份原理相当于一对一一行一行存储。并非将所有的记录备份到同一行的一个json中。当然也不得不承认 如果删除的数据过多。这块是否回台会hang。这块后期会增加一定限制。对于影响行数过多的数据。 当前提交的分支也并非我方当前最新的，就是因为担心影响范围过大，关于sqlserver、tidb和ck的逻辑没有增加。目前我司这边对于当前功能已经测试上线一月有余，后续还在通过jules快速迭代中。AI编写 人工审核。因此现在让我们拆分历史的分支会对我们后期的功能带来不可预知的问题，反而不如这一套代码稳定。毕竟当前这套代码目前生产工单已上线500+。

[codecov[bot]]

Codecov Report

:x: Patch coverage is 10.15936% with 451 lines in your changes missing coverage. Please review. :white_check_mark: Project coverage is 76.64%. Comparing base (9932db8) to head (7ef4dc1). :warning: Report is 11 commits behind head on master.

Files with missing lines	Patch %	Lines
sql/engines/dameng.py	7.95%	451 Missing :warning:

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3027      +/-   ##
==========================================
- Coverage   78.51%   76.64%   -1.88%     
==========================================
  Files         125      126       +1     
  Lines       17822    18324     +502     
==========================================
+ Hits        13993    14044      +51     
- Misses       3829     4280     +451     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.