geomative/GeomativeStudio/.qoder/repowiki/zh/content/安装与配置/配置说明/版本与数据库配置.md

版本与数据库配置

**本文档中引用的文件** - [version_info.txt](file://version_info.txt) - [database_modify.xml](file://database_modify.xml) - [DB\数据库字段修改记录.txt](file://DB/数据库字段修改记录.txt) - [cpp\Operator\UpdateDataBase.cpp](file://cpp/Operator/UpdateDataBase.cpp) - [h\UpdateDataBase.h](file://h/UpdateDataBase.h) - [cpp\Tools\checkupdate.cpp](file://cpp/Tools/checkupdate.cpp) - [h\checkupdate.h](file://h/checkupdate.h)

目录

1. 版本控制机制
2. 数据库变更管理
3. XML与文本格式对比
4. 系统升级流程
5. 部署与维护建议

版本控制机制

version_info.txt 文件是系统版本控制的核心元数据文件，其主要作用是存储当前软件的版本信息，支持自动更新功能。该文件位于安装目录中，其内容结构简单，仅包含一个版本号字段。

根据文件内容分析，当前版本号为 2.4.1。该版本号在系统启动时被读取，并与服务器端的最新版本进行比对，以判断是否需要执行更新操作。

版本比对逻辑主要在 checkupdate.cpp 文件中实现。系统通过 GetGeoMativeVersion() 函数从可执行文件的资源中提取版本信息，并通过 HTTP 请求从服务器获取最新的版本号（GeomativeVersion.txt）。如果本地版本低于服务器版本，则触发更新流程。

版本控制流程如下：

1. 系统启动时读取 version_info.txt 中的版本号
2. 通过 HTTP 请求获取服务器端最新版本号
3. 比较本地与远程版本号
4. 若本地版本较旧，则提示用户更新或自动下载更新包
5. 更新完成后，更新本地版本信息

该机制确保了软件能够及时获取最新功能和安全补丁，同时避免了不必要的更新操作。

本节来源

• version_info.txt
• cpp\Tools\checkupdate.cpp
• h\checkupdate.h

数据库变更管理

database_modify.xml 文件是数据库结构变更管理的核心配置文件，采用 XML 格式存储数据库的变更历史。该文件详细记录了数据库表结构的增删改操作，包括字段属性、主键、索引、外键等元数据信息。

XML结构分析

该文件采用分层结构，根节点为 current_version，包含当前版本号。其子节点 pre_version 记录了历史版本的变更信息。每个 pre_version 节点包含一个 value 属性，表示该版本号。

在 pre_version 节点下，table 元素表示对数据库表的操作，其 modify_type 属性定义了操作类型：

• 1: 增加表
• 2: 删除表
• 3: 修改表

column 元素描述了字段的详细属性：

• name: 字段名称
• is_primary_key: 是否为主键
• value_type: 字段类型（1:text, 2:Memo, 3:Byte, 4:Integer, 5:Long, 6:Single, 7:Double, 8:Currency, 9:AutoNumber, 10:Date/Time, 11:Yes/No）
• attribute_value: 字段长度（仅对文本类型有效）
• index: 索引类型（0:无索引, 1:允许重复, 2:不允许重复）
• is_foreign_key: 是否为外键
• is_empty: 是否允许为空
• is_compress: 是否压缩

变更执行流程

数据库变更的执行由 UpdateDataBase.cpp 中的 CUpdateDataBase 类负责。其工作流程如下：

flowchart TD
A[启动系统] --> B{是否存在database_modify.xml?}
B --> |否| C[无需更新数据库]
B --> |是| D[解析XML文件]
D --> E[获取当前数据库版本]
E --> F[查找匹配的pre_version]
F --> G[提取变更指令]
G --> H{遍历变更指令}
H --> I[增加表]
H --> J[删除表]
H --> K[修改表]
I --> L[生成CREATE TABLE语句]
J --> M[生成DROP TABLE语句]
K --> N[生成ALTER TABLE语句]
L --> O[执行SQL]
M --> O
N --> O
O --> P[更新versioninfo表]
P --> Q[完成数据库更新]

图示来源

• database_modify.xml
• cpp\Operator\UpdateDataBase.cpp
• h\UpdateDataBase.h

当系统检测到数据库需要更新时，会按照以下步骤执行：

1. 读取 database_modify.xml 文件
2. 解析当前版本号，查找对应的变更记录
3. 根据 modify_type 执行相应的数据库操作
4. 更新数据库中的 versioninfo 表，记录新的版本号
5. 记录更新日志到 LOG\update_db.log

本节来源

• database_modify.xml
• cpp\Operator\UpdateDataBase.cpp
• h\UpdateDataBase.h

XML与文本格式对比

系统中存在两种数据库变更记录格式：结构化的 XML 格式和纯文本格式。database_modify.xml 采用 XML 格式，而 DB\数据库字段修改记录.txt 则采用纯文本格式。

文本格式分析

纯文本格式的变更记录位于 DB\数据库字段修改记录.txt 文件中，其内容为人工编写的变更日志，按时间顺序记录了数据库的变更历史。例如：

2015年6月2日---
1：td2dcon增加字段bUse,用于标记该条记录是否有效
2：td3dcon增加字段bUse,用于标记该条记录是否有效
3: td1dcon增加字段bUse,用于标记该条记录是否有效

这种格式的优点是易于人类阅读和编写，但存在以下局限性：

• 缺乏结构化，难以自动化解析
• 没有标准化的字段类型定义
• 无法精确描述索引、外键等复杂约束
• 容易出现格式不一致的问题

XML格式优势

相比之下，database_modify.xml 的 XML 格式具有显著优势：

1. 结构化存储：采用标准化的标签和属性，便于程序解析和处理
2. 自动化处理：可以直接映射到数据库操作指令，实现自动化迁移
3. 完整性：包含完整的字段属性定义，包括数据类型、长度、约束等
4. 可验证性：可以通过 XML Schema 进行格式验证
5. 版本控制：支持多版本变更记录的嵌套管理

XML 格式特别适合在自动化部署和持续集成环境中使用，能够确保数据库结构变更的准确性和一致性。

本节来源

• database_modify.xml
• DB\数据库字段修改记录.txt

系统升级流程

当系统需要进行数据库结构升级时，会依据 version_info.txt 和 database_modify.xml 两个文件执行完整的迁移流程。

升级触发条件

系统在启动时会检查以下条件来决定是否需要升级：

1. 本地版本号与服务器版本号不一致
2. 数据库版本号与 database_modify.xml 中的版本号不一致
3. 存在未应用的 pre_version 变更记录

升级执行过程

升级过程由 CUpdateDataBase 类的 ParserUpdateDBXml() 方法驱动，其核心逻辑如下：

1. 版本比对：比较 m_strCurVer（当前版本）与 XML 中的 current_version 值
2. 变更查找：遍历 pre_version 节点，找到与当前数据库版本匹配的变更记录
3. 指令解析：根据 modify_type 解析表结构变更指令
4. SQL生成：将 XML 指令转换为具体的 SQL 语句
5. 事务执行：在数据库事务中执行所有变更操作
6. 版本更新：更新 versioninfo 表中的版本号

实际案例

假设系统从版本 1.1.1 升级到 1.1.2，需要在 test 表中添加新字段。database_modify.xml 中的配置如下：

<table name="test" modify_type="1">
    <column name="id" is_primary_key="1" value_type="9" attribute_value="1"/>
    <column name="col1" value_type="2" attribute_value="20" is_empty="1" is_compress="1"/>
    <column name="col2" value_type="5" is_foreign_key="0" refer_table_name="FK_test" refer_table_col="fk1"/>
    <column name="col3" value_type="5" index="2"/>
</table>

系统将生成以下 SQL 语句并执行：

CREATE TABLE test (
    id counter primary key,
    col1 text(20) with compression null,
    col2 integer,
    col3 integer
);
CREATE UNIQUE INDEX iCol3 ON test (col3);
ALTER TABLE test ADD CONSTRAINT FK_col2 FOREIGN KEY (col2) REFERENCES FK_test(fk1) ON UPDATE CASCADE ON DELETE CASCADE;

此过程确保了数据库结构变更的原子性和一致性。

本节来源

• version_info.txt
• database_modify.xml
• cpp\Operator\UpdateDataBase.cpp

部署与维护建议

version_info.txt 和 database_modify.xml 作为关键的元数据文件，在部署、备份和故障恢复中扮演着重要角色。

部署注意事项

1. 文件完整性：确保两个文件在部署包中完整存在
2. 版本同步：确保 version_info.txt 中的版本号与实际软件版本一致
3. 权限设置：确保应用程序有读写这两个文件的权限
4. 路径正确：确认文件位于正确的安装目录中

备份策略

建议将这两个文件纳入常规备份范围：

• version_info.txt：记录当前系统状态，便于版本追溯
• database_modify.xml：包含数据库变更历史，是数据恢复的关键

故障恢复

当系统出现故障时，这两个文件可帮助快速恢复：

1. 通过 version_info.txt 确定系统版本
2. 通过 database_modify.xml 重建数据库结构
3. 按照变更历史逐步恢复数据

维护建议

为确保文件的准确性和完整性，建议：

1. 变更审计：每次数据库结构变更都必须更新 database_modify.xml
2. 版本递增：每次发布新版本都必须更新 version_info.txt
3. 格式验证：使用 XML 验证工具确保 database_modify.xml 的格式正确
4. 文档同步：保持 XML 文件与数据库实际结构的一致性
5. 测试验证：在测试环境中验证变更脚本的正确性

通过严格维护这两个元数据文件，可以确保系统的稳定运行和可维护性。

本节来源

• version_info.txt
• database_modify.xml
• cpp\Operator\UpdateDataBase.cpp