Skip to content

Commit c1eafe4

Browse files
authored
docs(schema): add schema versioning (#3845)
Signed-off-by: Jiyong Huang <huangjy@emqx.io>
1 parent 6bd24c6 commit c1eafe4

File tree

3 files changed

+59
-1
lines changed

3 files changed

+59
-1
lines changed

docs/en_US/api/restapi/schemas.md

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -111,3 +111,36 @@ PUT http://localhost:9081/schemas/protobuf/{name}
111111
"file": "http://ahot.com/test2.proto"
112112
}
113113
```
114+
115+
## Versioning
116+
117+
The schema can have an optional **version** field. This field is essential for controlling updates and ensuring that new
118+
schemas are correctly applied. When you update a schema, the system compares the new version string to the existing one.
119+
An update is only accepted if the new version is **lexically greater** than the old one. This comparison is a
120+
character-by-character string comparison, not a numerical one.
121+
122+
### Versioning Logic
123+
124+
- **No Version Specified:** If neither the old nor the new schema has a `version` field, the update will proceed. This
125+
behavior aligns with the original, unversioned logic.
126+
- **Versioning Set:** If a `version` field is present in either the old or the new schema, the system will always
127+
perform a version comparison. The presence of any version string triggers the new comparison logic.
128+
- **Lexical Comparison:** Updates are based on a lexical (string) comparison. The new schema's `version` must be
129+
lexicographically greater than the current one for the update to be successful.
130+
- **Smallest Version:** A schema without a `version` field is considered to have the "smallest possible" version. This
131+
means that adding a version field to an existing, unversioned schema will always result in a successful update, as any
132+
new version string will be lexically greater than the non-existent one.
133+
134+
To avoid confusion and ensure correct ordering, it's highly recommended to use a **timestamp** as the version string.
135+
Timestamps, such as Unix epoch time, provide a universally unique and monotonically increasing value that naturally
136+
satisfies the lexical comparison rule.
137+
138+
Below is an example schema request with version:
139+
140+
```json
141+
{
142+
"name": "schema2",
143+
"file": "file:///tmp/ekuiper/internal/schema/test/test2.proto",
144+
"version": "1756436910"
145+
}
146+
```

docs/en_US/guide/serialization/protobuf_tutorial.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ message Book {
2525
2. In the schema creation window, fill in the fields as shown in the following figure. The schema type is `protobuf`; the schema name can be entered as a custom unique name to identify the schema id in the subsequent rule creation; the schema content can be filled in as a file or text content. If you choose file, you need to fill in the url of the file; the schema used in this tutorial is simple, so you can choose content and fill in the text of the proto file in the content box.
2626
![create schema detail](./resources/create_detail.png)
2727
3. Click Submit. You should be able to see the newly created schema in the list of schemas. You can then use the buttons in the action bar to modify or delete it.
28-
![lsit schemas](./resources/list_schema.png)
28+
![list schemas](./resources/list_schema.png)
2929

3030
At this point, we have registered a schema named `schema1`, which defines the type `Book`, and the registered schema can be used in the source and sink of the rule. Users can also continue to register and manage more schemas in this page.
3131

docs/zh_CN/api/restapi/schemas.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -112,3 +112,28 @@ PUT http://localhost:9081/schemas/protobuf/{name}
112112
"file": "http://ahot.com/test2.proto"
113113
}
114114
```
115+
116+
## 版本控制 (Versioning)
117+
118+
模式(schema)可以包含一个可选的 **version** 字段。此字段对于控制更新和确保正确应用新模式至关重要。当您更新一个模式时,系统会将新的版本字符串与现有版本进行比较。只有当新版本在
119+
**词典顺序上更大**时,更新才会被接受。这个比较是逐个字符的字符串比较,而不是数值比较。
120+
121+
### 版本控制逻辑
122+
123+
- **未指定版本**:如果新旧模式都没有 `version` 字段,更新将直接进行。此行为与原始未版本化模式的逻辑一致。
124+
- **已设置版本**:如果新旧模式中有一个包含 `version` 字段,系统将始终执行版本比较。任何版本字符串的存在都会触发新的比较逻辑。
125+
- **词典比较**:更新基于词典(字符串)比较。为了使更新成功,新模式的 `version` 必须在词典顺序上大于当前版本。
126+
- **最小版本**:不带 `version` 字段的模式被视为具有“最小可能”版本。这意味着,向一个现有的、未版本化的模式添加 `version`
127+
字段总能成功更新,因为任何新的版本字符串在词典顺序上都会大于不存在的版本。
128+
129+
为了避免混淆并确保正确的顺序,强烈建议使用**时间戳**作为版本字符串。例如,Unix 纪元时间戳可以提供一个全球唯一且单调递增的值,这天然满足了词典比较规则。
130+
131+
以下是一个带有版本字段的模式请求示例:
132+
133+
```json
134+
{
135+
"name": "schema2",
136+
"file": "file:///tmp/ekuiper/internal/schema/test/test2.proto",
137+
"version": "1756436910"
138+
}
139+
```

0 commit comments

Comments
 (0)