... | ... | @@ -159,80 +159,43 @@ data_type: |
|
|
* catalog 定义数据库连接参数
|
|
|
* data_type 定义某一种要处理的数据对应数据库里的一张或多张表
|
|
|
|
|
|
|配置项目|是否必填|数据类型|说明|
|
|
|
|----|----|----|----|
|
|
|
|compatible|选填|布尔|配置文件兼容选项|
|
|
|
|catalogues|必填|字典数组||
|
|
|
|default_data_type|选填|字符串|当数据中没有指明数据类型(data_type)时,默认使用的数据类型|
|
|
|
|default_operation|选填|字符串|当数据中没有指明操作(operation)时,默认使用的操作方式|
|
|
|
|
|
|
### compatible
|
|
|
早期的配置文件在设计上存在一个问题: 配置中dict的key可能是用户自定义的内容。
|
|
|
这样做虽然可以让配置相对简洁, 但配置文件的可读性并不好。
|
|
|
为了能具备更好的可读性,新版本中修改了配置的形式。新的配置形式中确保配置中
|
|
|
dict的key都是程序所设置的保留字。
|
|
|
|
|
|
如下示例,data_type新老两个版本不同的配置方式。
|
|
|
|
|
|
```yaml
|
|
|
#老版本的配置
|
|
|
# teams是用户自定义的data_type,
|
|
|
# 其值是teams这个data_type对应的数据库。
|
|
|
#
|
|
|
data_type:
|
|
|
- teams: ['tb_teams', 'tb_members']
|
|
|
```
|
|
|
|
|
|
```yaml
|
|
|
#新版本的配置
|
|
|
# name, tables都是程序的配置项,含义明确
|
|
|
data_type:
|
|
|
- name: "teams"
|
|
|
tables: ['tb_teams', 'tb_members']
|
|
|
```
|
|
|
考虑到已经有大量的配置文件在生产中使用,程序中保留了对老样式的兼容。
|
|
|
默认情况下,程序开启兼容模式(compatible:True)。可能的话请关闭兼容模式,
|
|
|
因为, 所有的新功能的开发,都将只支持非兼容模式。
|
|
|
|
|
|
### catalog
|
|
|
catalog 定义一个数据库连接。一个catalog中只能定义一种数据库连接参数。
|
|
|
通常把使用的相同连接参数的data_type配置在一个catalog中。
|
|
|
当然也可以根据需要放在多个catalog中。
|
|
|
|
|
|
### data_type
|
|
|
定义某一种要处理的数据。它与前续处理模块输出的数据类型相对应。
|
|
|
这个数据类型通常是业务层面的一种数据。如,一条被执行人信息。
|
|
|
通常这样一条业务数据以一个确定的JSON格式在数据系统中传递。
|
|
|
但业务层面的一条数据在存储到数据库时,可能对应的是一张表也可能是多张表。
|
|
|
而data_type的定义,就是指明入库模块收到的某一种数据类型所对应的数据库表是哪些。
|
|
|
布尔类型。
|
|
|
True 使用老版本的配置模式。 提供该选项只是为了保证已经存在的配置文件仍然可以工作。
|
|
|
False 以本文档当前说明的方式进行配置。新写的配置文件都应该设置为False
|
|
|
|
|
|
### default_data_type和default_operation
|
|
|
当数据中没有指明数据类型或操作时。则默认使用这两项所设置的值。如果在数据中对data_type和
|
|
|
operation进行了设置,则忽略该选项
|
|
|
|
|
|
### table_explode
|
|
|
<!--FIXME 名字建议改一改。
|
|
|
这个字段改为data_explode更为合理。因为这是对数据的操作,而非对表的操作
|
|
|
解释用途, 提供样例
|
|
|
-->
|
|
|
table_explode中定义了要炸开数据
|
|
|
表table_b的b_list的字段在输入的一条数据上要炸开,table_b产生一变多的效果入库
|
|
|
表table_c的c_list的字段在输入的一条数据上要炸开,table_c产生一变多的效果入库
|
|
|
|
|
|
### table_match
|
|
|
<!--FIXME 是正则表达式吗?-->
|
|
|
<!--FIXME 名字建议改一改。
|
|
|
这个功能是对输入的数据进行过滤。而不是针对表进行匹配。data_match 更为合理
|
|
|
-->
|
|
|
### catalogues (catalog数组)
|
|
|
|
|
|
table_match中定义了数据要匹配正则表达式才可以入库:
|
|
|
table_b: "b1=='5' and b2=='5'", table_b要匹配正则才可以入库
|
|
|
table_c: ["c1=='5'", "c3=='4'"], table_c匹配list中任意一个正则就可以入库(正则之间或的关系)
|
|
|
|
|
|
### db_start_transaction:
|
|
|
<!--TODO 解释用途, 提供样例-->
|
|
|
db_start_transaction定义事务的级别信息,isolation_level: "READ COMMITTED"主要解决的INSERT INTO on duplicate key update
|
|
|
会产生死锁的现象
|
|
|
数组类型。
|
|
|
|
|
|
它的每个元素均是一个字典,我们称为catalog。 catalog的选项如下表:
|
|
|
|
|
|
|配置项目|是否必填|数据类型|说明|
|
|
|
|----|----|----|----|
|
|
|
|[data_type](sync_mysql_new/catalog)|必填|数组||
|
|
|
|[db_connection](sync_mysql_new/catalog)|必填|字典||
|
|
|
|[table_explode](sync_mysql_new/table_explode)|选填|数组||
|
|
|
|[db_start_transaction](sync_mysql_new/catalog)|选填|||
|
|
|
|[add_return_keys](sync_mysql_new/catalog)|选填|||
|
|
|
|[table_match](sync_mysql_new/catalog)|选填|||
|
|
|
|
|
|
### add_return_keys
|
|
|
<!--TODO 解释用途,提供数据样例-->
|
|
|
add_return_keys定义的返回的结果上需要新加一列,键名为company_name_digest
|
|
|
|
|
|
一个catalog中只能定义一种数据库连接参数。 通常把使用的相同连接参数的data_type配置在一个catalog中。
|
|
|
当然也可以根据需要放在多个catalog中。
|
|
|
|
|
|
|
|
|
## 3. 应用场景说明
|
|
|
## 应用场景说明
|
|
|
<!--TODO 举几个典型的应用场景的配置。内容包括:
|
|
|
1. 场景的描述
|
|
|
2. 配置样例
|
... | ... | @@ -250,10 +213,7 @@ add_return_keys定义的返回的结果上需要新加一列,键名为company_ |
|
|
### 只对符合某些条件的数据进行操作(过滤)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### 配置样例
|
|
|
## 配置样例
|
|
|
以下样例配置,定义了两个catalog:一个指向db_host1上的数据库database1,另一个指向
|
|
|
db_host2上的database2。
|
|
|
|
... | ... | |