@lotics/app-sdk 0.87.4 → 0.87.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/docs/workflows.md +18 -1
- package/package.json +1 -1
package/docs/workflows.md
CHANGED
|
@@ -489,7 +489,7 @@ differ from `<` / `>` (code-unit order) and from the database's collation.
|
|
|
489
489
|
| `set` | `{ fld_x: value }` | write the whole value. `null` **clears** the field |
|
|
490
490
|
| `set_skip_null` | `{ fld_x: value }` | same shape, but `null`/`undefined` entries are **dropped** — absent means "leave unchanged" |
|
|
491
491
|
| `add_to` / `remove_from` / `replace` | `{ fld_x: [items] }` | surgical edits on multi-value fields (files, multi select, multi member, record links) |
|
|
492
|
-
| `increment` | `{ fld_x: delta }` | move a **number** field by a signed amount. Negative decrements; there is no separate decrement op |
|
|
492
|
+
| `increment` | `{ fld_x: delta }` | move a **number** field by a signed amount, the SAME delta on every record named. Negative decrements; there is no separate decrement op |
|
|
493
493
|
| `field_edits` | `[{ field, op, value }]` | the multi-value ops with the field named by a **string expression** — the only way to target a field chosen at run time. `increment` has no value-form: its payload is a scalar, not an item list |
|
|
494
494
|
|
|
495
495
|
`add_to`, `remove_from` and `increment` are RELATIVE: the server resolves them against the record
|
|
@@ -505,6 +505,23 @@ stating its value.
|
|
|
505
505
|
and visibly so. It is rejected on formula, rollup, lookup and autonumber fields: those come from
|
|
506
506
|
their own definition, so change what they aggregate instead.
|
|
507
507
|
|
|
508
|
+
A **different** delta per record is per-record mode with `row_op: "increment"` — every row value is
|
|
509
|
+
read as a delta rather than a value to write. That is the shape a stock move needs, since each item
|
|
510
|
+
moves by its own quantity:
|
|
511
|
+
|
|
512
|
+
```ts
|
|
513
|
+
await update_records({
|
|
514
|
+
table_id: "tbl_items",
|
|
515
|
+
record_ids: ids,
|
|
516
|
+
field_keys: ["fld_stock"],
|
|
517
|
+
rows: [[-12], [-3]],
|
|
518
|
+
row_op: "increment",
|
|
519
|
+
});
|
|
520
|
+
```
|
|
521
|
+
|
|
522
|
+
It also removes the read: the deltas are what the workflow already computed, so there is nothing to
|
|
523
|
+
look up first.
|
|
524
|
+
|
|
508
525
|
Inside `set` and `create_records.records`: `null` clears (persisted), `undefined` or an omitted
|
|
509
526
|
key preserves. So passing a possibly-null read straight through is safe. Use
|
|
510
527
|
`coalesce(x, fallback)` only when you want a real fallback, never to "strip" null.
|