9.3 KiB
9.3 KiB
RuoYi-Vue KingbaseES (人大金仓) 事实核验报告
核验原则:本轮核验基于 POM 静态解析、本地环境探测与语法特征比对,未修改任何工程文件与配置,未执行任何 DDL/DML,未输出任何密码凭据。
一、PageHelper 版本与配置核验
1. 精确版本
pagehelper-spring-boot-starter:1.4.7- 其默认传递依赖的 core
pagehelper:5.3.3
2. 继承与依赖链路
- 属性定义:父工程 pom.xml 中定义:
<pagehelper.boot.version>1.4.7</pagehelper.boot.version> - 依赖管控:父工程 pom.xml 的
<dependencyManagement>声明:<dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>${pagehelper.boot.version}</version> </dependency> - 模块引入:子模块 ruoyi-common/pom.xml 显式引入(省略版本,继承自父 POM):
<dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> </dependency> ruoyi-framework和ruoyi-admin通过依赖ruoyi-common间接获得该 starter。
3. application.yml 当前完整 PageHelper 配置
在 ruoyi-admin/src/main/resources/application.yml 中:
# PageHelper分页插件
pagehelper:
helperDialect: mysql
supportMethodsArguments: true
params: count=countSql
二、Kingbase Maven 依赖设计与仓库核验
1. 所有 POM 中的 Kingbase 坐标
- 父工程 pom.xml(
<dependencyManagement>):<dependency> <groupId>com.kingbase</groupId> <artifactId>kingbase8</artifactId> <version>8.6.0</version> </dependency> - 子模块 ruoyi-admin/pom.xml:
<dependency> <groupId>com.kingbase</groupId> <artifactId>kingbase8</artifactId> <version>8.6.0</version> </dependency>
2. 仓库配置(Repositories & PluginRepositories)
全项目所有 POM 中仅在根 pom.xml 配置了阿里云公共镜像:
<repository>:https://maven.aliyun.com/repository/public(ID:public)<pluginRepository>:https://maven.aliyun.com/repository/public(ID:public)
3. ~/.m2/settings.xml 与私有仓库
~/.m2/settings.xml文件:不存在。- 项目中 未配置任何 Nexus、Artifactory 或企业私有 Maven 仓库。
4. maven-dependency-plugin 完整 Execution 节点
在父工程 pom.xml 与 ruoyi-admin/pom.xml 中均存在如下完整配置:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>copy-dependencies</id>
<phase>package</phase>
<goals>
<goal>copy-dependencies</goal>
</goals>
<configuration>
<!-- 输出目录 -->
<outputDirectory>D:\maven_repository\com\kingbase\kingbase8\8.6.0</outputDirectory>
<!-- 包含运行时依赖 -->
<includeScope>runtime</includeScope>
<!-- 包含编译时依赖 -->
<includeScope>compile</includeScope>
<!-- 可选:包含指定的 groupId -->
<includeGroupIds>com.kingbase</includeGroupIds>
<!-- 可选:包含指定的 artifactId -->
<includeArtifactIds>kingbase8</includeArtifactIds>
</configuration>
</execution>
</executions>
</plugin>
5. 为何使用 com.kingbase:kingbase8:8.6.0
- 交付与部署习惯:人大金仓商业安装包自带的驱动文件通常命名为
kingbase8-8.6.0.jar。在国企信创标准交付中,官方推荐通过命令行将其安装至本地 Maven 仓库:mvn install:install-file -Dfile=kingbase8-8.6.0.jar -DgroupId=com.kingbase -DartifactId=kingbase8 -Dversion=8.6.0 -Dpackaging=jar - 开发者环境痕迹:原工程作者在 Windows 环境(
D:\maven_repository)下开发,采用离线介质手动安装,未通过企业 Nexus 私服托管。因此代码中固定约定了该标准坐标。
三、数据库客户端工具与模式查询获取条件
1. 本机客户端工具排查
ksql:未安装(which ksql返回 not found)。psql:未安装(which psql返回 not found)。DataGrip CLI:未安装(系统无相关命令行软链接)。- 其他连接工具:Python 未安装
psycopg2/asyncpg,且无任何直接可用的数据库 CLI 工具。
2. 是否能直接执行 SHOW database_mode;
- 结论:目前无法直接执行。
- 原因:本机缺少连接 KingbaseES 所需的交互式 CLI 客户端工具;在未配置工具且不修改环境的前提下,无法向远程数据库发送查询指令。
四、审计项重新分类(基于数据库兼容模式视角)
KingbaseES V8R6 具备 Oracle、PostgreSQL (PG)、MySQL 三种兼容器模式。不同模式下的内置函数、引号解析规则存在显著差异。
1. CONFIRMED(不依赖 database_mode 也确定存在的问题)
- 本地缺失 Kingbase 驱动 Jar:本地 Maven 仓库确实不存在对应 jar 包,公网仓库无此包,阻断 Maven 编译构建。
- 构建插件硬编码 Windows 绝对路径:
D:\maven_repository\...写死在pom.xml中,在 macOS/Linux 打包时必然引发异常。 - 代码生成器表名过滤逻辑缺陷 (
GenTableMapper.xml):where table_schema = (select current_database())。在 Kingbase 所有模式下,current_database()返回的均为数据库名(如training),而information_schema.tables.table_schema记录的是 schema 名(如public),必然导致查不到任何表。 - 代码生成器字段元数据语法与视图缺陷 (
GenTableColumnMapper.xml): 使用了非标逻辑符&&;且column_key、extra、column_comment在 Kingbase 的information_schema.columns中不作为标准列存在。
2. MODE_DEPENDENT(是否有问题取决于 database_mode)
- **反引号(
)**(SysMenuMapper.xml中的 ``query` ``):- 若为 MySQL 模式:原生支持反引号,无问题。
- 若为 PG / Oracle 模式:反引号为非法字符,直接报错(必须双引号
")。
date_format(14 处):- 若为 MySQL 模式:支持 MySQL 日期格式化函数,无问题。
- 若为 PG / Oracle 模式:无原生
date_format函数,直接报错(除非库内自建了兼容函数)。
find_in_set(3 处):- 若为 MySQL 模式:内置支持,无问题。
- 若为 PG / Oracle 模式:无原生函数,直接报错。
ifnull(4 处):- 若为 MySQL 模式:内置支持,无问题。
- 若为 Oracle 模式(主推
nvl)或 PG 模式(主推coalesce):可能报错。
helperDialect=mysql:- 若为 MySQL 模式:MySQL 分页语法与机制高度吻合,影响较小。
- 若为 Oracle 模式:MySQL 分页语法(
LIMIT ? OFFSET ?)与 Oracle 模式不兼容,必定报错。
SELECT 1 FROM DUAL:- 若为 Oracle / MySQL 模式:支持
DUAL虚表,完全合法可用。 - 若为 纯 PG 模式:若未建 DUAL 视图则报错。
- 若为 Oracle / MySQL 模式:支持
3. RUNTIME_TEST_REQUIRED(必须连库执行只读 SQL 才能确定)
- 实际
database_mode的值:需连库执行SHOW database_mode;才能确认到底处于何种模式。 - 远端 training 库的表是否已建好:如果库中已有全量业务与系统表,则项目自带的初始化 SQL 无需再次执行;若为空库,则必须确认 DDL。
- 库中是否已预装兼容函数:某些企业现场会在 public 下预建
date_format、find_in_set标量函数。
4. LOW_PRIORITY(不阻塞目前业务开发的问题)
GROUP_CONCAT:全局 Mapper XML 扫描结果为 0 处,实际未被使用,不构成障碍。- MySQL JDBC 驱动残留:
mysql-connector-java虽声明但未被主数据源激活,仅有依赖冗余,不阻塞开发。 public.schema 前缀零星硬编码:当前 JDBC URL 已配置currentSchema=public,写与不写均能正确定位到 public 下的表,不影响当前运行。- 初始化脚本为 MySQL 语法 (
sql/ry_*.sql,sql/quartz.sql):仅影响从零全新建库,若远程开发数据库已就绪,则不影响本地业务开发。