a
This commit is contained in:
coco
@@ -0,0 +1,238 @@
|
||||
# 版本与数据库配置
|
||||
|
||||
<cite>
|
||||
**本文档中引用的文件**
|
||||
- [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)
|
||||
</cite>
|
||||
|
||||
## 目录
|
||||
1. [版本控制机制](#版本控制机制)
|
||||
2. [数据库变更管理](#数据库变更管理)
|
||||
3. [XML与文本格式对比](#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](file://version_info.txt)
|
||||
- [cpp\Tools\checkupdate.cpp](file://cpp/Tools/checkupdate.cpp)
|
||||
- [h\checkupdate.h](file://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` 类负责。其工作流程如下：
|
||||
|
||||
```mermaid
|
||||
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](file://database_modify.xml)
|
||||
- [cpp\Operator\UpdateDataBase.cpp](file://cpp/Operator/UpdateDataBase.cpp)
|
||||
- [h\UpdateDataBase.h](file://h/UpdateDataBase.h)
|
||||
|
||||
当系统检测到数据库需要更新时，会按照以下步骤执行：
|
||||
1. 读取 `database_modify.xml` 文件
|
||||
2. 解析当前版本号，查找对应的变更记录
|
||||
3. 根据 `modify_type` 执行相应的数据库操作
|
||||
4. 更新数据库中的 `versioninfo` 表，记录新的版本号
|
||||
5. 记录更新日志到 `LOG\update_db.log`
|
||||
|
||||
**本节来源**
|
||||
- [database_modify.xml](file://database_modify.xml)
|
||||
- [cpp\Operator\UpdateDataBase.cpp](file://cpp/Operator/UpdateDataBase.cpp)
|
||||
- [h\UpdateDataBase.h](file://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](file://database_modify.xml)
|
||||
- [DB\数据库字段修改记录.txt](file://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` 中的配置如下：
|
||||
|
||||
```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 语句并执行：
|
||||
```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](file://version_info.txt)
|
||||
- [database_modify.xml](file://database_modify.xml)
|
||||
- [cpp\Operator\UpdateDataBase.cpp](file://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](file://version_info.txt)
|
||||
- [database_modify.xml](file://database_modify.xml)
|
||||
- [cpp\Operator\UpdateDataBase.cpp](file://cpp/Operator/UpdateDataBase.cpp)
|
||||
Reference in New Issue
Block a user