无处不在

> 我觉得可能有问题： > > 1. Statement.RETURN_GENERATED_KEYS 是JDBC定义的标准，数据库不兼容我觉得是数据库的问题比较大，是否需要做兼容得再看看 > > 2. 使用你的新方式我觉得可能的问题是如果表的主键字段不是id怎么办 目前系统中，用到的几处(好像是3处吧)Statement.RETURN_GENERATED_KEYS都是具体业务模块的，不多，基本主键都是id，如果不一样就多定义几个常量就行了。 我之所以建议改这个，也是希望多数据源出现之前，把系统那些明显的不兼容的方式，更改为通用的方式。

@i will solve it@ 看错误提示是对象序列化问题，应该上次别人提交的批量实例处理的代码，我提交了一个PR，希望可以被社区合并

个人不建议使用Type作为字段名称，这个字段是某些数据库的关键字

我之前还想该这种类似的东西呢，可是没有人反馈，没想到被你抢先了， 关联一下我之前发的ISSUE吧：#8765

楼主那个方案短期内应该不适用，改动比较大吧。 # 我的设计说明 我本地自己基于Nacos2.1实现了一版多数据源的设计，支持核心config模块等，虽然其他辅助功能暂时未测试，常见的config操作都可以，目前支持PostgreSQL和Oracle，准备在支持下DB2，计划最近在抽取优化一下，然后开源一下。你们要是喜欢，我马上就开源，或提供Oracle版本的2.1打包的格式部署文件。 修改文件截图如下：  这一个版本的设计类图如下：  ## SPI加载数据库方言设计 1、SPI初始化，增加DatabaseDialect方言类，封装分页等查询方法，使用方式为： dataSourceService = DynamicDataSource.getInstance().getDataSource(); databaseDialect = this.dataSourceService.databaseDialect(); ` @Override public String getTestQuery() { return " SELECT 1"; } @Override public...

> #8312 欢迎大家讨论起来，提供更好的建议 目前是处理了分页和其他基础相关，nacos大部分不兼容都在SELECT方面，其次就是DELETE分页删除方面，还有些其他辅助类写死的mysql语法支持。 短期内抽取SQL估计改动大。我们公司的BI系统也是类似的设计。

楼主的方案，个人觉得可以补充的是： 1、建议不影响Nacos核心外部调用PersistService的引用，同时将JdbcTemplate下沉到DB实现层 2、SPI不建议去封装那12张表的Mapper类，可以将那12张表的mapper组合到一个门面类里面，暴露的是多种数据库门面类的SPI，每个具体的SPI里面可以去维护Mapper 3、同时在PersistService类中引入委派模式，比如ExternalPersistDelegeService让，然后在委派里面调用SPI具体的某一个数据库的门面实现。 针对楼主的方案，个人补充的图片： 

> 你好，我们最近打算使用postgresql替换mysql，能否开源你的代码 可以看下我的Github个人主页，之前已经放到仓库中了，欢迎Star

我想提交这个GrpcClient代码中的serverCheck的PR是否可以呢？ Payload response = responseFuture.get(3000L, TimeUnit.MILLISECONDS); 主要是增加这个3000的一个常量和一个方法进行获取 ，这样就和该类中的其他属性判断一致了， private static final long DEFAULT_SERVERCHECK_TIMEOUT = 3000L; private int serverCheckTimeout() { String serverCheckTimeout = System .getProperty("nacos.remote.grpc.servercheck.timeout", String.valueOf(DEFAULT_SERVERCHECK_TIMEOUT)); return Integer.parseInt(serverCheckTimeout); } Payload response...

看后端代码中DumpService类删除的时候是支持参数的好像， String val = EnvUtil.getProperty("nacos.config.retention.days");，尝试添加下nacos.config.retention.days这个启动属性，这个默认是30