You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/plugins.md
+7-21Lines changed: 7 additions & 21 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -339,33 +339,19 @@ To include arbitrary data output from your job, which will be automatically pass
339
339
340
340
The format of the `data` object is freeform, and can contain whatever content you want. Note that the above example is pretty-printed for display, but in practice all messages must be sent as single lines, so remember to compact your JSON when serializing it.
341
341
342
-
Note that if you send multiple messages containing `data`, the top-level data object properties are shallow-merged (the latter prevails on duplicate keys). Using this you can add data incrementally during a job run.
343
-
344
-
As an advanced option, you can also incrementally *append to arrays* inside the `data` object using this syntax:
342
+
Note that if you send multiple messages containing `data` within the same job, the top-level data object properties are shallow-merged (the latter prevails on duplicate keys). Using this you can add data incrementally during a job run. Additionally, if you are overwriting a top-level array with another array, it will be *concatenated* instead of replaced. Example:
345
343
346
344
```json
347
-
{
348
-
"xy": 1,
349
-
"push": {
350
-
"data.arr": [0, 1, 2]
351
-
}
352
-
}
345
+
{ "xy": 1, "data": { "arr": [0, 1, 2] } }
353
346
```
354
347
355
-
This would append to an array named `arr` (it will be created if needed). You can use simple `dot.path.notation` to access any array deep inside the data object.
356
-
357
-
Then, if you sent an additional message with another `push` on the same array like this:
348
+
Then later, in the same job:
358
349
359
350
```json
360
-
{
361
-
"xy": 1,
362
-
"push": {
363
-
"data.arr": [3, 4, 5]
364
-
}
365
-
}
351
+
{ "xy": 1, "data": { "arr": [3, 4, 5] } }
366
352
```
367
353
368
-
The `arr` array would grow accordingly, and contain all 6 elements upon job completion.
354
+
This would end up with `[0, 1, 2, 3, 4, 5]` in the final `arr` data array when the job completes.
369
355
370
356
##### Output Files
371
357
@@ -487,9 +473,9 @@ To update the [Workflow Data](workflows.md#sharing-data-between-all-nodes) for t
487
473
}
488
474
```
489
475
490
-
Note that the workflow data is shallow-merged, so you can specify a sparsely-populated object and it will only add / replace the included top-level properties. If your job outputs multiple messages with `workflowData` they are all shallow-merged together.
476
+
Note that the workflow data is shallow-merged, so you can specify a sparsely-populated object and it will only add / replace the included top-level properties. If your job outputs multiple messages with `workflowData` they are all shallow-merged together. Additionally, top-level arrays are concatenated when merging.
491
477
492
-
The workflow data is only updated when the job completes.
478
+
The workflow data is only updated in the parent workflow when the sub-job completes.
Copy file name to clipboardExpand all lines: docs/workflows.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -206,7 +206,7 @@ xyOps offers another way to share data between nodes, including nodes that are n
206
206
{ "xy": 1, "workflowData": { "foo": "bar" } }
207
207
```
208
208
209
-
The data is shallow-merged into the shared `workflowData` object when the sub-job completes. Then, any subsequent jobs that launch from the same workflow are passed the updated `workflowData` object.
209
+
The data is shallow-merged into the shared `workflowData` object when the sub-job completes (also, top-level arrays are concatenated together instead of replacing). Then, any subsequent jobs that launch from the same workflow are passed the updated `workflowData` object.
210
210
211
211
The `workflowData` object only lasts for the duration of the workflow run. It is not persistent like [Server User Data](servers.md#user-data), but it works in the same way.
0 commit comments