This is an automated email from the ASF dual-hosted git repository.
SbloodyS pushed a commit to branch dev
in repository https://gitbox.apache.org/repos/asf/dolphinscheduler.git
The following commit(s) were added to refs/heads/dev by this push:
new 9a86abea47 [Doc-18322][Parameter] Add a note to the parameter priority
documentation specifying and fix some issues (#18323)
9a86abea47 is described below
commit 9a86abea47ec5b94f7107bc35931f0d676004621
Author: njnu-seafish <[email protected]>
AuthorDate: Fri Jun 5 18:17:24 2026 +0800
[Doc-18322][Parameter] Add a note to the parameter priority documentation
specifying and fix some issues (#18323)
---
docs/docs/en/guide/parameter/priority.md | 9 +++++----
docs/docs/zh/guide/parameter/priority.md | 9 +++++----
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/docs/docs/en/guide/parameter/priority.md
b/docs/docs/en/guide/parameter/priority.md
index 03f06468bb..e3354e206b 100644
--- a/docs/docs/en/guide/parameter/priority.md
+++ b/docs/docs/en/guide/parameter/priority.md
@@ -2,6 +2,7 @@
DolphinScheduler has three parameter types:
+* [Built-in Parameter](built-in.md): parameters built into the system
* [Project-level Parameter](project-parameter.md): parameters defined at the
project management page.
* [Global Parameter](global.md): parameters defined at the workflow define
page.
* [Startup Parameter](startup-parameter.md): parameters defined at the
workflow launch page.
@@ -10,7 +11,7 @@ DolphinScheduler has three parameter types:
The user can define part of the parameters when creating workflow definitions.
-As there are multiple sources of the parameter value, it will raise parameter
priority issues when the parameter name is the same. The priority of
DolphinScheduler parameters from high to low is: `Parameter Context > Startup
Parameter > Local Parameter > Global Parameter > Project-level Parameter`.
+As there are multiple sources of the parameter value, it will raise parameter
priority issues when the parameter name is the same. The priority of
DolphinScheduler parameters from high to low is: `Parameter Context > Startup
Parameter > Local Parameter > Global Parameter > Project-level Parameter >
Built-in Parameter`.
In the case of upstream tasks can pass parameters to the downstream, there may
be multiple tasks upstream that pass the same parameter name:
@@ -29,16 +30,16 @@ The [useParam] node can use the parameters which are set in
the [createParam] no
-The [createParam] node can use parameters directly. In addition, the node
creates two parameters named "key" and "key1", and "key1" has the same name as
the one passed by the upstream node and assign value "12". However, due to the
priority rules, the value assignment will assign "12" and the value from the
upstream node is discarded.
+The [useParam] node can use parameters directly. In addition, the
[createParam] node creates two parameters named "key" and "key1", and "key" has
the same name as the one passed by the upstream node and assign value "12".
However, due to the priority rules, the value assignment will assign "1" and
the value from local parameter inside this node is discarded.
2: Use SQL nodes to explain another case.
-The following shows the definition of the [use_create] node:
+The following shows the definition of the [use_param] node:
"status" is own parameter of the node set by the current node. However, the
user also sets the "status" parameter (global parameter) when saving the
process definition and assign its value to -1. Then the value of status will be
2, with higher priority when the SQL executes. The global parameter value is
discarded.
-The "ID" here is the parameter set by the upstream node. The user sets the
parameters of the same parameter name "ID" for the [createparam1] node and
[createparam2] node. And the [use_create] node uses the value of [createParam1]
which is finished first.
+The "ID" here is the parameter set by the upstream node. The user sets the
parameters of the same parameter name "ID" for the [useParam1] node and
[useParam2] node. And the [use_param] node uses the value of [useParam1] which
is finished first.
diff --git a/docs/docs/zh/guide/parameter/priority.md
b/docs/docs/zh/guide/parameter/priority.md
index 8226729b7c..0c8d0dc8ce 100644
--- a/docs/docs/zh/guide/parameter/priority.md
+++ b/docs/docs/zh/guide/parameter/priority.md
@@ -2,13 +2,14 @@
DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：
+* [内置参数](built-in.md)：在系统中内置的参数
* [项目级别参数](project-parameter.md)：在项目管理中定义的项目级别参数
* [全局参数](global.md)：在工作流保存页面定义时定义的变量
* [启动参数](startup-parameter.md)：在工作流启动页面定义的变量
* [上游任务传递的参数](context.md)：上游任务传递过来的参数
* [本地参数](local.md)：节点的自有变量，用户在“自定义参数”定义的变量，并且用户可以在工作流定义时定义该部分变量的值
-因为参数的值存在多个来源，当参数名相同时，就需要会存在参数优先级的问题。DolphinScheduler 参数的优先级从高到低为：`上游任务传递的参数 >
启动参数 > 本地参数 > 全局参数 > 项目级别参数`
+因为参数的值存在多个来源，当参数名相同时，就需要会存在参数优先级的问题。DolphinScheduler 参数的优先级从高到低为：`上游任务传递的参数 >
启动参数 > 本地参数 > 全局参数 > 项目级别参数 > 内置参数`
在上游任务传递的参数中，由于上游可能存在多个任务向下游传递参数，当上游传递的参数名称相同时：
@@ -27,16 +28,16 @@ DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：
-其中节点【createParam】在使用变量时直接使用即可。另外该节点设置了 "key" 和 "key1"
两个变量，这里用户用定义了一个与上游节点传递的变量名相同的变量 key1，并且赋值为 "12"，但是由于我们设置的优先级的关系，这里的值 "12"
会被使用，最终上游节点设置的变量值会被抛弃。
+其中节点【useParam】在使用变量时直接使用即可。另外节点【createParam】设置了 "key" 和 "key1"
两个变量，这里用户定义了一个与上游节点传递的变量名相同的变量 key，并且赋值为 "12"，但是由于我们设置的优先级的关系，这里的值 "12"
会被抛弃，最终上游节点设置的变量值会被使用。
2：我们再以 sql 节点来解释另外一种情况
-节点【use_create】的定义如下：
+节点【use_param】的定义如下：
"status" 是当前节点设置的节点的自有变量。但是用户在保存工作流时也同样设置了 "status" 变量（全局参数），并且赋值为 -1。那在该 SQL
执行时，status 的值为优先级更高的 2。抛弃了全局变量中的值。
-这里的 "id" 是上游节点设置的变量，用户在节点【createParam1】、节点【createParam2】中设置了相同参数名 "id"
的参数。而节点【use_create】中使用了最先结束的【createParam1】的值。
+这里的 "id" 是上游节点设置的变量，用户在节点【useParam1】、节点【useParam2】中设置了相同参数名 "id"
的参数。而节点【use_param】中使用了最先结束的【useParam1】的值。
