v8.5: update TiCDC Debezium DDL, WATERMARK support - #21885
Conversation
lilin90
added
translation/from-docs
lilin90
changed the title
ti-chi-bot
Bot
added
the
size/XXL
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthrough文档扩展 TiCDC Debezium Protocol 说明，覆盖新旧架构支持差异、DDL、DML 和 WATERMARK 事件格式、schema 定义、字段语义，以及 TiCDC 与原生 Debezium 的数据类型差异。 ChangesTiCDC Debezium 协议文档
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: 🟡 Moderate · up to The updated TiCDC Debezium examples describe payload fields that are not declared in their corresponding schemas, which can mislead users and break expectations for schemaful integrations. Correct the examples or explicitly accept this compatibility risk before merging. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| | `schema.fields` | JSON | `payload` 中各个字段的类型信息。 | | ||
| | `schema.type` | 字符串 | 字段类型。 | | ||
| | `schema.optional` | 布尔值 | 该字段是否为选填项。值为 `true` 表示该字段为选填项。 | | ||
| | `schema.version` | 字符串 | schema 的版本。 | |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
修正 schema.version 的类型。
JSON 示例中的值是数值 1，但说明表将其标为字符串。请保持说明表与 JSON schema 一致。
可直接提交的替换
| | `schema.version` | 字符串 | schema 的版本。 | | |
| | `schema.version` | 数值 | schema 的版本。 | |
As per path instructions：此文件匹配 **/*.md；可安全替换连续 diff 行的可操作问题必须使用 GitHub 可提交的 suggestion block。
Source: Path instructions
| "fields": [ | ||
| { | ||
| "field": "source", | ||
| "name": "io.debezium.connector.mysql.Source", | ||
| "optional": false, | ||
| "type": "struct", | ||
| "fields": [ | ||
| { | ||
| "field": "version", | ||
| "optional": false, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "connector", | ||
| "optional": false, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "name", | ||
| "optional": false, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "ts_ms", | ||
| "optional": false, | ||
| "type": "int64" | ||
| }, | ||
| { | ||
| "field": "snapshot", | ||
| "optional": true, | ||
| "type": "string", | ||
| "parameters": { | ||
| "allowed": "true,last,false,incremental" | ||
| }, | ||
| "default": "false", | ||
| "name": "io.debezium.data.Enum", | ||
| "version": 1 | ||
| }, | ||
| { | ||
| "field": "db", | ||
| "optional": false, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "sequence", | ||
| "optional": true, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "table", | ||
| "optional": true, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "server_id", | ||
| "optional": false, | ||
| "type": "int64" | ||
| }, | ||
| { | ||
| "field": "gtid", | ||
| "optional": true, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "file", | ||
| "optional": false, | ||
| "type": "string" | ||
| }, | ||
| { | ||
| "field": "pos", | ||
| "optional": false, | ||
| "type": "int64" | ||
| }, | ||
| { | ||
| "field": "row", | ||
| "optional": false, | ||
| "type": "int32" | ||
| }, | ||
| { | ||
| "field": "thread", | ||
| "optional": true, | ||
| "type": "int64" | ||
| }, | ||
| { | ||
| "field": "query", | ||
| "optional": true, | ||
| "type": "string" | ||
| } |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟠 Major | 🏗️ Heavy lift
对齐三个事件的 source schema。
三个示例的 payload.source 都包含 commit_ts 和 cluster_id，但对应的 io.debezium.connector.mysql.Source schema 没有声明这两个字段。文档中的 payload 和 schema 因此不是同一个线协议。Schema 驱动的消费者可能丢弃或拒绝这两个 TiDB 扩展字段。
请在 DDL、DML 和 WATERMARK 的 Source schema 中补齐字段及其实际类型，或从 payload 示例中移除字段，并使用实际生成的消息验证。
As per path instructions：此问题跨越多个非连续位置，且需要以实际 wire contract 确认，因此使用普通 review comment。
Also applies to: 528-556, 658-746
Source: Path instructions
| | `payload.tableChanges.table.primaryKeyColumnNames` | 字符串 | 组成表主键的列的名称列表。 | | ||
| | `payload.tableChanges.table.columns` | 数组 | 变更的表中每一列的元数据。 | | ||
| | `payload.tableChanges.table.columns.name` | 字符串 | 列的名称。 | | ||
| | `payload.tableChanges.table.columns.jdbcType` | 数值 | 列的 JDBC 类型。 | | ||
| | `payload.tableChanges.table.columns.comment` | 字符串 | 列的注释。 | | ||
| | `payload.tableChanges.table.columns.defaultValueExpression` | 字符串 | 列的默认值。 | | ||
| | `payload.tableChanges.table.columns.enumValues` | 字符串 | 列的枚举值。格式为 `['e1', 'e2']`。 | | ||
| | `payload.tableChanges.table.columns.charsetName` | 字符串 | 列的字符集。 | | ||
| | `payload.tableChanges.table.columns.length` | 数值 | 列的长度。 | | ||
| | `payload.tableChanges.table.columns.scale` | 数值 | 列的精度。 | |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
修正 tableChanges 字段说明的类型和语义。
说明表与后面的 JSON 和 schema 不一致：
primaryKeyColumnNames是字符串数组。enumValues是字符串数组。scale表示小数位数，不是精度。
可直接提交的替换
| | `payload.tableChanges.table.primaryKeyColumnNames` | 字符串 | 组成表主键的列的名称列表。 | | |
| | `payload.tableChanges.table.columns` | 数组 | 变更的表中每一列的元数据。 | | |
| | `payload.tableChanges.table.columns.name` | 字符串 | 列的名称。 | | |
| | `payload.tableChanges.table.columns.jdbcType` | 数值 | 列的 JDBC 类型。 | | |
| | `payload.tableChanges.table.columns.comment` | 字符串 | 列的注释。 | | |
| | `payload.tableChanges.table.columns.defaultValueExpression` | 字符串 | 列的默认值。 | | |
| | `payload.tableChanges.table.columns.enumValues` | 字符串 | 列的枚举值。格式为 `['e1', 'e2']`。 | | |
| | `payload.tableChanges.table.columns.charsetName` | 字符串 | 列的字符集。 | | |
| | `payload.tableChanges.table.columns.length` | 数值 | 列的长度。 | | |
| | `payload.tableChanges.table.columns.scale` | 数值 | 列的精度。 | | |
| | `payload.tableChanges.table.primaryKeyColumnNames` | 字符串数组 | 组成表主键的列的名称列表。 | |
| | `payload.tableChanges.table.primaryKeyColumnNames` | 字符串 | 组成表主键的列的名称列表。 | | |
| | `payload.tableChanges.table.columns` | 数组 | 变更的表中每一列的元数据。 | | |
| | `payload.tableChanges.table.columns.name` | 字符串 | 列的名称。 | | |
| | `payload.tableChanges.table.columns.jdbcType` | 数值 | 列的 JDBC 类型。 | | |
| | `payload.tableChanges.table.columns.comment` | 字符串 | 列的注释。 | | |
| | `payload.tableChanges.table.columns.defaultValueExpression` | 字符串 | 列的默认值。 | | |
| | `payload.tableChanges.table.columns.enumValues` | 字符串 | 列的枚举值。格式为 `['e1', 'e2']`。 | | |
| | `payload.tableChanges.table.columns.charsetName` | 字符串 | 列的字符集。 | | |
| | `payload.tableChanges.table.columns.length` | 数值 | 列的长度。 | | |
| | `payload.tableChanges.table.columns.scale` | 数值 | 列的精度。 | | |
| | `payload.tableChanges.table.columns.enumValues` | 字符串数组 | 列的枚举值列表。格式为 `['e1', 'e2']`。 | |
| | `payload.tableChanges.table.primaryKeyColumnNames` | 字符串 | 组成表主键的列的名称列表。 | | |
| | `payload.tableChanges.table.columns` | 数组 | 变更的表中每一列的元数据。 | | |
| | `payload.tableChanges.table.columns.name` | 字符串 | 列的名称。 | | |
| | `payload.tableChanges.table.columns.jdbcType` | 数值 | 列的 JDBC 类型。 | | |
| | `payload.tableChanges.table.columns.comment` | 字符串 | 列的注释。 | | |
| | `payload.tableChanges.table.columns.defaultValueExpression` | 字符串 | 列的默认值。 | | |
| | `payload.tableChanges.table.columns.enumValues` | 字符串 | 列的枚举值。格式为 `['e1', 'e2']`。 | | |
| | `payload.tableChanges.table.columns.charsetName` | 字符串 | 列的字符集。 | | |
| | `payload.tableChanges.table.columns.length` | 数值 | 列的长度。 | | |
| | `payload.tableChanges.table.columns.scale` | 数值 | 列的精度。 | | |
| | `payload.tableChanges.table.columns.scale` | 数值 | 列的小数位数。 | |
As per path instructions：此文件匹配 **/*.md；可安全替换连续 diff 行的可操作问题必须使用 GitHub 可提交的 suggestion block。
Source: Path instructions
| | `payload.tableChanges.table.columns.position` | 数值 | 列的位置。 | | ||
| | `payload.tableChanges.table.columns.optional` | 布尔值 | 是否为可选列。值为 `true` 表示为可选列。 | | ||
| | `schema.fields` | JSON | `payload` 每个字段的类型信息，包括变更表的列 schema 信息。 | | ||
| | `schema.name` | 字符串 | schema 的名称，格式为 `"{cluster-name}.{schema-name}.{table-name}.SchemaChangeValue"`。 | |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -eu
file='ticdc/ticdc-debezium.md'
printf '%s\n' '--- target context ---'
sed -n '400,455p' "$file"
printf '%s\n' '--- schema.name references ---'
rg -n -C 3 'schema\.name|SchemaChangeValue|schemaName' "$file" ticdc 2>/dev/null || true
printf '%s\n' '--- repository references ---'
rg -n -C 2 'SchemaChangeValue|schema\.name' . --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**' 2>/dev/null | head -300Repository: pingcap/docs-cn
Length of output: 14119
🌐 Web query:
TiCDC Debezium schema.name SchemaChangeValue cluster-name schema-name table-name
💡 Result:
In the TiCDC Debezium protocol, the schema.name field follows a structured naming convention designed to uniquely identify the schema definition for different parts of the message [1][2][3]. The format is "{cluster-name}.{schema-name}.{table-name}.{suffix}", where the suffix indicates the specific type of the message payload [1][2][4]. The documented suffixes include: - SchemaChangeValue: Used when the schema information relates to DDL or schema change events [1][4]. - Envelope: Used for the primary DML event structure (the "wrapper" containing the operation type, source info, and data) [2][3]. - Key: Used specifically for the schema of the primary key or unique index columns within the payload [2][3]. In this format, {cluster-name} refers to the TiDB cluster identifier, {schema-name} refers to the upstream database name, and {table-name} refers to the table name where the event occurred [1][2][5]. This hierarchical naming allows downstream consumers to parse and map the Debezium-formatted messages back to the correct database and table structures [2][6].
Citations:
- 1: https://docs.pingcap.com/tidb/dev/ticdc-debezium/
- 2: https://docs.pingcap.com/tidb/stable/ticdc-debezium/
- 3: https://website-docs-preview.vercel.app/tidb/stable/ticdc-debezium/
- 4: https://github.com/ginkgoch/pingcap-docs/blob/master/ticdc/ticdc-debezium.md
- 5: https://docs.pingcap.com/zh/tidb/stable/ticdc-debezium/
- 6: https://docs.pingcap.com/tidb/v8.1/ticdc-debezium/
🌐 Web query:
site:github.com/pingcap/tiflow "SchemaChangeValue" "schema.name"
💡 Result:
The term SchemaChangeValue and the property schema.name do not appear together as a formal, documented API component in common technical frameworks. Based on technical documentation and codebases such as TiCDC (part of the TiFlow project), these terms appear in the context of specific internal structures: 1. Schema Handling: In projects like TiCDC, schema names are frequently handled as strings (often labeled schema.name or SchemaName) within data structures representing DDL (Data Definition Language) jobs or events [1]. 2. SchemaChange/Schema Value: The terminology "SchemaChange" often refers to internal events representing schema modifications (DDL operations like CREATE, ALTER, or DROP table/database) [2][1]. In this context, specific values associated with these events—such as the schema name, table name, query text, and timestamps—are stored in objects (often called DDL Jobs or Events) to track and replicate database state changes across distributed systems [2][1]. 3. Context: If you encountered this syntax in a specific configuration or code snippet, it is likely a reference to a field (schema.name) within an object or structure (like a SchemaChange or DDL event) used by a change data capture or database replication tool to identify the target database for a DDL operation [3][1]. If you are working with a specific software or library, please provide the name of the tool or the code snippet context for a more precise explanation.
Citations:
- 1: https://github.com/pingcap/tiflow/blob/8879687f/cdc/puller/ddl_puller.go
- 2: https://github.com/pingcap/tiflow/blob/8879687f/cdc/entry/schema_test.go
- 3: Support dispatch schema-level ddl to different topic tiflow#11882
🏁 Script executed:
#!/bin/bash
set -eu
printf '%s\n' '--- document metadata and nearby examples ---'
sed -n '1,180p' ticdc/ticdc-debezium.md
sed -n '450,610p' ticdc/ticdc-debezium.md
printf '%s\n' '--- repository history metadata for the target line ---'
git status --short
git diff -- ticdc/ticdc-debezium.md
git log --oneline -8 -- ticdc/ticdc-debezium.mdRepository: pingcap/docs-cn
Length of output: 12816
🌐 Web query:
site:github.com/pingcap/tiflow "io.debezium.connector.mysql.SchemaChangeValue"
💡 Result:
io.debezium.connector.mysql.SchemaChangeValue is not a public or standard class name documented within the official Debezium project. References to similar strings in technical contexts (such as GitHub repositories) typically represent custom implementations, internal classes, or documentation naming conventions for schema change event structures within specific downstream connectors or integrations, rather than a core Debezium API class [1][2][3]. In the official Debezium architecture: 1. Schema Change Events: Debezium connectors emit schema change events to notify downstream consumers of database structure modifications (like CREATE, ALTER, or DROP table/database operations) [4]. 2. Event Structure: These events provide detailed, structured metadata about schema changes, sparing consumers from having to manually parse complex DDL statements [4]. The payload typically includes information such as the database name, schema name, the raw DDL statement, and a structured representation of table changes [3]. 3. Configuration and Usage: While Debezium emits these events, they are distinct from the internal "schema history" mechanisms (which use classes like io.debezium.storage.kafka.history.KafkaSchemaHistory to persist state) [5]. Consumers or transformations (such as SMTs or custom filters) may refer to schema change value structures, sometimes using internal or informal naming (e.g., filter.SchemaChangeValue) in documentation examples or custom codebases [3]. 4. Integration Contexts: The specific string you encountered is often seen in third-party integrations, such as TiCDC (TiDB Change Data Capture), where developers implement or reference custom schemas for mapping Debezium-formatted events to other systems [1][2]. For authoritative details on schema change handling, refer to the Debezium documentation on schema change topics and connectors [3][5][4].
Citations:
- 1: pingcap/tiflow@0e0b615
- 2: [BUG][CDC]Debezium Protocal set error default value for the not null timestamp field. tiflow#11966
- 3: https://debezium.io/documentation/reference/3.5/transformations/schema-change-event-filter.html
- 4: https://debezium.io/blog/2020/05/07/debezium-1-2-beta1-released/
- 5: https://debezium.io/documentation/reference/3.2/configuration/storage.html
🌐 Web query:
site:github.com/pingcap/tiflow "SchemaChangeKey" "SchemaChangeValue"
💡 Result:
The terms "SchemaChangeKey" and "SchemaChangeValue" are not standard technical terms or public API constants in major software frameworks. Instead, they appear to be internal variables, enum members, or custom naming conventions used within the codebase of TiCDC (a component of the TiDB distributed database project) or similar event-driven data streaming systems [1][2][3]. In the context of data replication, schema change events often involve a structure that represents the mutation (the "change") and its associated metadata (the "key" or identifier of the schema object). Developers working with such systems may define structs or map keys named SchemaChangeKey and SchemaChangeValue to handle: 1. SchemaChangeKey: Typically represents the unique identifier or the structural path (e.g., database name, table name, or schema version ID) associated with a schema mutation [4][5]. 2. SchemaChangeValue: Represents the payload or the specific details of the schema change (e.g., the DDL statement, the modified table metadata, or the state before/after the change) [2][3]. These naming patterns are frequently found in test helpers or internal sink logic when serializing or debugging schema evolution events [1][3]. If you encountered these in a specific codebase, they are likely project-specific implementations rather than generic industry standards.
Citations:
- 1: sink(ticdc): add event key output for debezium tiflow#11649
- 2: https://github.com/pingcap/tiflow/blob/8879687f/cdc/entry/schema_test.go
- 3: https://github.com/pingcap/tiflow/blob/8879687f/cdc/entry/schema_test_helper.go
- 4: [CDC:ErrSnapshotSchemaNotFound] schema 41766 not found in schema snapshot tiflow#9476
- 5: https://github.com/pingcap/tiflow/blob/8879687f/cdc/puller/ddl_puller.go
🏁 Script executed:
#!/bin/bash
set -eu
api='https://api.github.com/repos/pingcap/tiflow/git/trees/master?recursive=1'
curl -fsSL "$api" |
jq -r '.tree[] | select(.type == "blob" and (.path | test("debezium|Debezium"; "i"))) | .path' |
head -200Repository: pingcap/docs-cn
Length of output: 202
🏁 Script executed:
#!/bin/bash
set -eu
for url in \
'https://github.com/pingcap/tiflow/commit/0e0b615a916230e6fa4ca1385f8ddafd0762f36c.patch' \
'https://raw.githubusercontent.com/pingcap/tiflow/master/cdc/sink/codec/debezium/codec.go' \
'https://raw.githubusercontent.com/pingcap/tiflow/master/cdc/sink/codec/debezium/debezium.go'
do
printf '\n--- %s ---\n' "$url"
curl -L --fail --silent --show-error "$url" |
rg -n -C 4 'SchemaChange(Value|Key)|schema(Name)?|Envelope|cluster' |
head -240 || true
doneRepository: pingcap/docs-cn
Length of output: 10028
🌐 Web query:
"test_cluster.test.table1.SchemaChangeValue" TiCDC
💡 Result:
In TiCDC, "SchemaChangeValue" is part of the naming convention for schema-related event metadata, specifically within the context of message protocols (such as Avro or Debezium) used when streaming data to downstream systems like Kafka [1]. When TiCDC replicates data, it serializes schema information to ensure downstream consumers can correctly interpret the data payload [1]. The identifier "test_cluster.test.table1.SchemaChangeValue" follows the naming pattern "{cluster-name}.{schema-name}.{table-name}.SchemaChangeValue," which serves as the "schema.name" property in the message metadata [1]. This field informs the downstream consumer about the structure and type information of the columns within the table being replicated, allowing the consumer to adapt to changes as the upstream table schema evolves [1][2]. TiCDC manages these schema changes by tracking versions and applying the correct schema snapshot to each event based on its commit timestamp [2]. This ensures that even in distributed environments where schema changes occur concurrently with data modifications (DML), the downstream system maintains a consistent view of the data [2].
Citations:
- 1: https://github.com/ginkgoch/pingcap-docs/blob/master/ticdc/ticdc-debezium.md
- 2: https://www.pingcap.com/blog/multi-writer-change-data-capture-cdc-architecture-ticdc-tidb/
🌐 Web query:
"SchemaChangeValue" "test_cluster" TiCDC
💡 Result:
In the context of TiCDC, SchemaChangeValue refers to a specific component of the message schema used in the Debezium protocol [1][2]. Specifically, it is part of the naming convention for the schema name of a message, which typically follows the format {cluster-name}.{schema-name}.{table-name}.SchemaChangeValue [1]. The Debezium protocol in TiCDC allows TiCDC to integrate with systems that expect Debezium-formatted change data [1][3]. In this protocol, the schema of a message includes metadata about the changed data, and SchemaChangeValue identifies the structure of the schema change information associated with an event [1][4][2]. Regarding the term test_cluster, this is likely a placeholder or naming convention used in documentation or configuration examples for identifying the specific TiDB cluster from which data is being replicated [1]. When configuring TiCDC, you specify the cluster, and it is reflected in the event metadata to ensure that downstreams can correctly identify and process the source of the incoming change events [1][5].
Citations:
- 1: https://github.com/ginkgoch/pingcap-docs/blob/master/ticdc/ticdc-debezium.md
- 2: https://github.com/pingcap/docs-cn/blob/master/ticdc/ticdc-debezium.md
- 3: https://medium.com/@firmanbrilian/change-data-capture-cdc-from-tidb-to-data-lake-or-warehouse-38a60a8e973f
- 4: https://github.com/jiong-nba/tidb_docs/blob/master/ticdc/ticdc-debezium.md
- 5: https://docs.pingcap.com/tidb/stable/ticdc-simple-protocol/
将 schema.name 说明改为固定名称
DDL 协议实际使用固定值 io.debezium.connector.mysql.SchemaChangeValue，不使用集群、数据库和表名拼接格式。
建议修改
| | `schema.name` | 字符串 | schema 的名称，格式为 `"{cluster-name}.{schema-name}.{table-name}.SchemaChangeValue"`。 | | |
| | `schema.name` | 字符串 | schema 的名称，固定为 `io.debezium.connector.mysql.SchemaChangeValue`。 | |
Source: Path instructions
| | schema.optional | 布尔值 | optional 为 `true` 时表示该字段为选填项 | | ||
| | schema.type | 字符串 | 表示该字段的数据类型 | | ||
| | `payload` | JSON | 主键或唯一索引列的信息。每个字段的 key 和 value 分别为列名和当前值。 | | ||
| | `schema.fields` | JSON | `payload` 中各个字段的类型信息，包括对应行数据变更前后 schema 的信息。 | |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
分别描述 DML Key 和 WATERMARK 的 schema.fields。
DML Key 只包含主键或唯一索引字段，不包含 before 或 after schema。WATERMARK 也没有行数据的 before 或 after。当前说明沿用了 DML Value 的描述。
可直接提交的替换
| | `schema.fields` | JSON | `payload` 中各个字段的类型信息，包括对应行数据变更前后 schema 的信息。 | | |
| | `schema.fields` | JSON | `payload` 中各个 Key 字段的类型信息。 | |
| | `schema.fields` | JSON | `payload` 中各个字段的类型信息，包括对应行数据变更前后 schema 的信息。 | | |
| | `schema.fields` | JSON | `payload` 中各个字段的类型信息，包括 `source`、`op`、`ts_ms` 和 `transaction`。 | |
As per path instructions：此文件匹配 **/*.md；可安全替换连续 diff 行的可操作问题必须使用 GitHub 可提交的 suggestion block。
Also applies to: 796-796
Source: Path instructions
|
|
||
| - TiCDC 将 REAL 转换为 DOUBLE；当长度为 1 时，将 BOOLEAN 转换为 TINYINT(1)。 | ||
|
|
||
| - 在 TiCDC 中，BLOB、TEXT、GEOMETRY、JSON 列没有默认值。 |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
移除与 TiDB 支持范围矛盾的 GEOMETRY 说明。
前文说明 TiDB 不支持 GEOMETRY，但此处又将其列为 TiCDC 的默认值处理差异。请删除该项或明确其不是 TiCDC 支持范围内的行为。
可直接提交的替换
| - 在 TiCDC 中，BLOB、TEXT、GEOMETRY、JSON 列没有默认值。 | |
| - 在 TiCDC 支持的数据类型中，`BLOB`、`TEXT` 和 `JSON` 列没有默认值。TiDB 不支持 `GEOMETRY`，因此本节不描述其默认值行为。 |
As per path instructions：此文件匹配 **/*.md；可安全替换连续 diff 行的可操作问题必须使用 GitHub 可提交的 suggestion block。
Source: Path instructions
Co-authored-by: Grace Cai <qqzczy@126.com>
[LGTM Timeline notifier]Timeline:
|
Co-authored-by: Grace Cai <qqzczy@126.com>
|
@wk989898: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
@qiancai: Your lgtm message is repeated, so it is ignored. DetailsIn response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lilin90 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
3 participants
What is changed, added or deleted? (Required)
Updated the TiCDC Debezium support for DDL, WATERMARK events in new and classic TiCDC architectures.
Which TiDB version(s) do your changes apply to? (Required)
Tips for choosing the affected version(s):
By default, CHOOSE MASTER ONLY so your changes will be applied to the next TiDB major or minor releases. If your PR involves a product feature behavior change or a compatibility change, CHOOSE THE AFFECTED RELEASE BRANCH(ES) AND MASTER.
For details, see tips for choosing the affected versions (in Chinese).
What is the related PR or file link(s)?
AI agent involvement
Do your changes match any of the following descriptions?
Summary by CodeRabbit
newarch配置说明。