This is an automated email from the ASF dual-hosted git repository.
zhongjiajie pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dolphinscheduler-website.git
The following commit(s) were added to refs/heads/master by this push:
new 13d472f Proofreading dev documents under /user_doc/guide/parameter
(#722)
13d472f is described below
commit 13d472f5c644064aa4d490321a5b0c6332827fd3
Author: Tq <[email protected]>
AuthorDate: Thu Mar 10 11:00:38 2022 +0800
Proofreading dev documents under /user_doc/guide/parameter (#722)
---
.../en-us/dev/user_doc/guide/parameter/built-in.md | 22 ++++++------
docs/en-us/dev/user_doc/guide/parameter/context.md | 39 ++++++++++++----------
docs/en-us/dev/user_doc/guide/parameter/global.md | 6 ++--
docs/en-us/dev/user_doc/guide/parameter/local.md | 6 ++--
.../en-us/dev/user_doc/guide/parameter/priority.md | 28 ++++++++--------
.../zh-cn/dev/user_doc/guide/parameter/priority.md | 2 +-
6 files changed, 53 insertions(+), 50 deletions(-)
diff --git a/docs/en-us/dev/user_doc/guide/parameter/built-in.md
b/docs/en-us/dev/user_doc/guide/parameter/built-in.md
index 5e666fe..ddb2edb 100644
--- a/docs/en-us/dev/user_doc/guide/parameter/built-in.md
+++ b/docs/en-us/dev/user_doc/guide/parameter/built-in.md
@@ -3,41 +3,41 @@
## Basic Built-in Parameter
<table>
- <tr><th>variable</th><th>declaration method</th><th>meaning</th></tr>
+ <tr><th>Variable</th><th>Declaration Method</th><th>Meaning</th></tr>
<tr>
<td>system.biz.date</td>
<td>${system.biz.date}</td>
- <td>The day before the scheduled time of the daily scheduling
instance, the format is yyyyMMdd</td>
+ <td>The day before the schedule time of the daily scheduling instance,
the format is yyyyMMdd</td>
</tr>
<tr>
<td>system.biz.curdate</td>
<td>${system.biz.curdate}</td>
- <td>The timing time of the daily scheduling instance, the format is
yyyyMMdd</td>
+ <td>The schedule time of the daily scheduling instance, the format is
yyyyMMdd</td>
</tr>
<tr>
<td>system.datetime</td>
<td>${system.datetime}</td>
- <td>The timing time of the daily scheduling instance, the format is
yyyyMMddHHmmss</td>
+ <td>The schedule time of the daily scheduling instance, the format is
yyyyMMddHHmmss</td>
</tr>
</table>
## Extended Built-in Parameter
-- Support custom variable names in the code, declaration method: \${variable
name}. It can refer to [basic built-in parameter](#basic-built-in-parameter) or
specify "constants".
+- Support custom variables in the code, declaration way: `${variable name}`.
Refers to "System Parameter".
-- We define this benchmark variable as \$[...] format, \$[yyyyMMddHHmmss] can
be decomposed and combined arbitrarily, such as: \$[yyyyMMdd], \$[HHmmss],
\$[yyyy-MM-dd], etc.
+- Benchmark variable defines as `$[...]` format, time format
`$[yyyyMMddHHmmss]` can be decomposed and combined arbitrarily, such as:
`$[yyyyMMdd]`, `$[HHmmss]`, `$[yyyy-MM-dd]`, etc.
-- Or the 2 following methods may be useful:
+- Or define by the 2 following ways:
- 1. use add_month(yyyyMMdd, offset) function to add/minus number of months
- the first parameter of this function is yyyyMMdd, representing the time
format user will get
- the second is offset, representing the number of months the user wants
to add or minus
+ 1. Use add_month(yyyyMMdd, offset) function to add or minus number of
months
+ the first parameter of this function is [yyyyMMdd], represents the time
format
+ the second parameter is offset, represents the number of months the user
wants to add or minus
* Next N years：$[add_months(yyyyMMdd,12*N)]
* N years before：$[add_months(yyyyMMdd,-12*N)]
* Next N months：$[add_months(yyyyMMdd,N)]
* N months before：$[add_months(yyyyMMdd,-N)]
*********************************************************************************************************
- 1. add numbers directly after the time format
+ 1. Add or minus numbers directly after the time format
* Next N weeks：$[yyyyMMdd+7*N]
* First N weeks：$[yyyyMMdd-7*N]
* Next N days：$[yyyyMMdd+N]
diff --git a/docs/en-us/dev/user_doc/guide/parameter/context.md
b/docs/en-us/dev/user_doc/guide/parameter/context.md
index 6fe9f9a..9277258 100644
--- a/docs/en-us/dev/user_doc/guide/parameter/context.md
+++ b/docs/en-us/dev/user_doc/guide/parameter/context.md
@@ -1,63 +1,66 @@
-# Parameter Context
+# Refer to Parameter Context
-DolphinScheduler provides the ability to refer to each other between
parameters, including: local parameters refer to global parameters, and
upstream and downstream parameter transfer. Because of the existence of
references, it involves the priority of parameters when the parameter names are
the same. see also [Parameter Priority](priority.md)
+DolphinScheduler provides the ability to refer to each other between
parameters, including local parameters refer to global parameters and upstream
and downstream parameter transfer. Due to the existence of references, it
involves the priority of parameters when the parameter names are the same. see
also [Parameter Priority](priority.md)
-## Local Task Use Global Parameter
+## Local Task Refers to Global Parameter
-The premise of local tasks referencing global parameters is that you have
already defined [Global Parameter](global.md). The usage is similar to the
usage in [local parameters](local.md), but the value of the parameter needs to
be configured as the key in the global parameter
+The premise of local tasks referring global parameters is that you have
already defined [Global Parameter](global.md). The usage is similar to the
usage in [local parameters](local.md), but the value of the parameter needs to
be configured as the key of the global parameter.
-As shown in the figure above, `${biz_date}` and `${curdate}` are examples of
local parameters referencing global parameters. Observe the last line of the
above figure, local_param_bizdate uses \${global_bizdate} to refer to the
global parameter. In the shell script, you can use \${local_param_bizdate} to
refer to the value of the global variable global_bizdate, or set the value of
local_param_bizdate directly through JDBC. In the same way, local_param refers
to the global parameters defi [...]
+As the figure above shows, `${biz_date}` and `${curdate}` are examples of
local parameters that refer to global parameters. Observe the last line of the
above figure, `local_param_bizdate` uses `${global_bizdate}` to refer to the
global parameter. In the shell script, you can use `${local_param_bizdate}` to
refer to the value of the global variable `global_bizdate`, or set the value of
`local_param_bizdate` directly through JDBC. Similarly, `local_param` refers to
the global parameters d [...]
## Pass Parameter From Upstream Task to Downstream
-DolphinScheduler Parameter transfer between tasks is allowed, and the current
transfer direction only supports one-way transfer from upstream to downstream.
The task types currently supporting this feature are：
+DolphinScheduler allows parameter transfer between tasks. Currently, transfer
direction only supports one-way transfer from upstream to downstream. The task
types that support this feature are：
* [Shell](../task/shell.md)
* [SQL](../task/sql.md)
* [Procedure](../task/stored-procedure.md)
-When defining an upstream node, if there is a need to transmit the result of
that node to a downstream node that has a dependency. You need to set a
parameter whose direction is OUT in [Custom Parameters] of [Current Node
Settings]. At present, we mainly focus on the function of SQL and SHELL nodes
that can input parameters.
+When defining an upstream node, if there is a need to transmit the result of
that node to a dependency related downstream node. You need to set an `OUT`
direction parameter to [Custom Parameters] of the [Current Node Settings]. At
present, we mainly focus on the SQL and shell nodes to pass parameters
downstream.
-prop is user-specified; the direction is selected as OUT, and will be defined
as parameter output only when the direction is OUT. The data type can be chosen
from different data structures as needed; the value part is not required.
+### SQL
-If the result of the SQL node has only one row, one or more fields, the name
of the prop needs to be the same as the field name. The data type can be chosen
to be something other than LIST. The parameter will select the value
corresponding to the column with the same name as this parameter in the column
name in the SQL query result.
+`prop` is user-specified; the direction selects `OUT`, and will define as an
export parameter only when the direction is `OUT`. Choose data structures for
data type according to the scenario, and the leave the value part blank.
-If the result of the SQL node is multiple rows, one or more fields, the name
of the prop needs to be the same as the name of the field. The data type is
selected as LIST, and the SQL query result will be converted to LIST, and the
result will be converted to JSON as the value of the corresponding parameter.
+If the result of the SQL node has only one row, one or multiple fields, the
name of the `prop` needs to be the same as the field name. The data type can
choose structure except `LIST`. The parameter assigns the value according to
the same column name in the SQL query result.
-Let's take another example of the process that contains the SQL node in the
above picture:
+If the result of the SQL node has multiple rows, one or more fields, the name
of the `prop` needs to be the same as the field name. Choose the data type
structure as `LIST`, and the SQL query result will be converted to
`LIST<VARCHAR>`, and forward to convert to JSON as the parameter value.
-The [createParam1] node in the above figure is defined as follows:
+Let's make an example of the SQL node process in the above picture:
+
+The [createParam1] node in the above figure defines as follows:
- [createParam2] node is defined as follows:
+The [createParam2] node defines as follows:
-You can find the value of the variable in the [Workflow Instance] page to find
the corresponding node instance.
+Find the value of the variable in the [Workflow Instance] page corresponding
to the node instance.
Node instance [createparam1] is as follows:
-Here, the value of "id" is equal to 12.
+Here, the value of "id" is 12.
Let's see the case of the node instance [createparam2].
-There is only the value of "id". Although the user-defined sql looks up the
fields "id" and "database_name", only one parameter is set because only one
parameter "id" is defined for out. For display reasons, the length of the list
is already checked for you here as 10.
+There is only the "id" value. Although the user-defined SQL query both "id"
and "database_name" field, only set the `OUT` parameter `id` due to only one
parameter "id" is defined for output. The length of the result list is 10 due
to display reasons.
### SHELL
-prop is user-specified. The direction is selected as OUT. The output is
defined as a parameter only when the direction is OUT. Data type can choose
different data structures as needed; the value part is not required to be
filled. The user needs to pass the parameter, and when defining the shell
script, the output format of ${setValue(key=value)} statement is required, key
is the prop of the corresponding parameter, and value is the value of the
parameter.
+`prop` is user-specified and the direction is `OUT`. The output is defined as
an export parameter only when the direction is `OUT`. Choose data structures
for data type according to the scenario, and leave the value part blank.
+The user needs to pass the parameter when creating the shell script, the
output statement format is `${setValue(key=value)}`, the key is the `prop` of
the corresponding parameter, and value is the value of the parameter.
For example, in the figure below:
-When the log detects the ${setValue(key=value1)} format in the shell node
definition, it will assign value1 to key, and the downstream node can use the
value of the variable key directly. Similarly, you can find the corresponding
node instance on the [Workflow Instance] page to see the value of the variable.
+When the log detects the `${setValue(key=value1)}` format in the shell node
definition, it will assign value1 to the key, and downstream nodes can use the
variable key directly. Similarly, you can find the corresponding node instance
on the [Workflow Instance] page to see the value of the variable.
diff --git a/docs/en-us/dev/user_doc/guide/parameter/global.md
b/docs/en-us/dev/user_doc/guide/parameter/global.md
index e9db8e7..bd4b25d 100644
--- a/docs/en-us/dev/user_doc/guide/parameter/global.md
+++ b/docs/en-us/dev/user_doc/guide/parameter/global.md
@@ -2,11 +2,11 @@
## Scope
-The parameters configured on the workflow definition dialog, the whole
workflow is it's scope.
+The parameters defined on the process definition page can apply to all the
scope of the process tasks.
## Usage
-the approach to set global parameters is, after defining the workflow, click
the 'save' button, then click the '+' button below the 'Set global':
+Usage of global parameters is: at the process define page, click the '+'
beside the 'Set global' and fill in the key and value to save:
<p align="center">
<img src="/img/supplement_global_parameter_en.png" width="80%" />
@@ -16,4 +16,4 @@ the approach to set global parameters is, after defining the
workflow, click the
<img src="/img/local_parameter_en.png" width="80%" />
</p>
-The global_bizdate parameter defined here can be referenced by local
parameters of any other task node, and the value of global_bizdate is set to
the figure obtained by referencing the system parameter system.biz.date
+The `global_bizdate` parameter defined here can be referenced by local
parameters of any other task node, and set the value of `global_bizdate` by
referencing the system parameter `system.biz.date`.
\ No newline at end of file
diff --git a/docs/en-us/dev/user_doc/guide/parameter/local.md
b/docs/en-us/dev/user_doc/guide/parameter/local.md
index 41e74f3..a764e7b 100644
--- a/docs/en-us/dev/user_doc/guide/parameter/local.md
+++ b/docs/en-us/dev/user_doc/guide/parameter/local.md
@@ -2,11 +2,11 @@
## Scope
-Parameters configured on the task definition dialog, the scope of this
parameter only for this task, but if you configured follow [Parameter
Context](context.md), it could passed follow task.
+Parameters configured on the task definition page, the scope of this parameter
is inside this task only. But if you configure according to [Refer to Parameter
Context](context.md), it could pass to downstream tasks.
## Usage
-The approach to set local parameters is, double-click on any node while
defining the workflow and click the '+' button next to the 'Custom Parameters':
+Usage of local parameters is: at the task define page, click the '+' beside
the 'Custom Parameters' and fill in the key and value to save:
<p align="center">
<img src="/img/supplement_local_parameter_en.png" width="80%" />
@@ -16,4 +16,4 @@ The approach to set local parameters is, double-click on any
node while defining
<img src="/img/global_parameter_en.png" width="80%" />
</p>
-If you want to call the [built-in parameter](built-in.md) in the local
parameters, fill in the value corresponding to the built-in parameters in
`value`, as in the above figure, `${biz_date}` and `${curdate}`
+If you want to call the [built-in parameter](built-in.md) in the local
parameters, fill in thevalue of built-in parameters in `value`. As in the above
figure, `${biz_date}` and `${curdate}`.
\ No newline at end of file
diff --git a/docs/en-us/dev/user_doc/guide/parameter/priority.md
b/docs/en-us/dev/user_doc/guide/parameter/priority.md
index 008684b..94bef18 100644
--- a/docs/en-us/dev/user_doc/guide/parameter/priority.md
+++ b/docs/en-us/dev/user_doc/guide/parameter/priority.md
@@ -1,33 +1,33 @@
# Parameter Priority
-DolphinScheduler definition of parameter values involved in may come from
three types:
+DolphinScheduler has three parameter types:
-* [Global Parameter](global.md): Parameters defined when the workflow saves
page definitions
-* [Parameter Context](context.md): Parameters passed by upstream nodes
-* [Local Parameter](local.md)：The node's own parameters, which is the
parameters defined by the user in [Custom Parameters]. The user can define the
value of this part of the parameters at the time of workflow definition.
+* [Global Parameter](global.md): parameters defined at the workflow define page
+* [Parameter Context](context.md): parameters passed by upstream task nodes
+* [Local Parameter](local.md): parameters belong to its node, which is the
parameters defined by the user in [Custom Parameters]. The user can define part
of the parameters when creating workflow definitions.
-Because the value of a parameter has multiple sources, when the parameter name
is the same, there needs to be a parameter priority problem. The priority of
DolphinScheduler parameters from high to low is: `Global Parameter > Parameter
Context > Local Parameter`
+Due to there are multiple sources of the parameter value, there will raise
parameter priority issues when the parameter name is the same. The priority of
DolphinScheduler parameters from high to low is: `Global Parameter > Parameter
Context > Local Parameter`
-In the case of parameters passed by the upstream task, there may be multiple
tasks upstream to pass parameters to the downstream. When the parameter names
passed upstream are the same:
+In the case of upstream tasks can pass parameters to the downstream, there may
be multiple tasks upstream that pass the same parameter name:
-* Downstream nodes will preferentially use parameters with non-empty values
-* If there are multiple parameters with non-empty values, sort according to
the completion time of the upstream task, and select the parameter
corresponding to the upstream task with the earliest completion time
+* Downstream nodes prefer to use parameters with non-empty values
+* If there are multiple parameters with non-empty values, select the value
from the upstream task with the earliest completion time
## Example
-For example, the relationships are shown in the figures below:
+Followings are examples shows task parameters priority problems:#############
-1: The first case is explained by the shell nodes.
+1: Use shell nodes to explain the first case.
-The [useParam] node can use the parameters which is set in the [createParam]
node. The [useParam] node does not have a dependency on the [noUseParam] node,
so it does not get the parameters of the [noUseParam] node. The above picture
is just an example of a shell node, other types of nodes have the same usage
rules.
+The [useParam] node can use the parameters which are set in the [createParam]
node. The [useParam] node cannot obtain the parameters from the [noUseParam]
node due to there is no dependency between them. Other task node types have the
same usage rules with shell example here.
-Among all, the [createParam] node can use parameters directly. In addition,
the node sets two parameters named "key" and "key1". Here the user defines a
parameter named "key1" with the same name as the one passed by the upstream
node and copies the value "12". However, due to the priority we set, the value
"12" here would be discarded and the parameter value set by the upstream node
would be finally used.
+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 "12" is discarded and the value from the
upstream node is finally used.
-2: Let's explain another situation in SQL nodes.
+2: Use SQL nodes to explain another case.
@@ -35,6 +35,6 @@ The definition of the [use_create] node is as follows:
-"status" is the own parameters of the node set by the current node. However,
the user also sets the "status" parameter when saving, assigning its value to
-1. Then the value of status will be -1 with higher priority when the SQL is
executed. The value of the node's own variable is discarded.
+"status" is the own parameters of the node and set by the current node.
However, the user also sets the "status" parameter when saving, assigning its
value to -1. Then the value of status will be -1 with higher priority when the
SQL is executed. The value of the node's own variable 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.
\ No newline at end of file
diff --git a/docs/zh-cn/dev/user_doc/guide/parameter/priority.md
b/docs/zh-cn/dev/user_doc/guide/parameter/priority.md
index f9b9d8a..9aeaea4 100644
--- a/docs/zh-cn/dev/user_doc/guide/parameter/priority.md
+++ b/docs/zh-cn/dev/user_doc/guide/parameter/priority.md
@@ -25,7 +25,7 @@ DolphinScheduler 中所涉及的参数值的定义可能来自三种类型：
<img src="/img/globalParam/image-20210723103316896.png"
alt="image-20210723103316896" style="zoom:50%;" />
-其中节点【createParam】在使用变量时直接使用即可。另外该节点设置了 "key" 和 "key1"
两个变量，这里用户用定义了一个与上游节点传递的变量名相同的变量 key1，并且复制了值为 "12"，但是由于我们设置的优先级的关系，这里的值 "12"
会被抛弃，最终使用上游节点设置的变量值。
+其中节点【createParam】在使用变量时直接使用即可。另外该节点设置了 "key" 和 "key1"
两个变量，这里用户用定义了一个与上游节点传递的变量名相同的变量 key1，并且赋值为 "12"，但是由于我们设置的优先级的关系，这里的值 "12"
会被抛弃，最终使用上游节点设置的变量值。
2：我们再以 sql 节点来解释另外一种情况
