Table Type

Creation Syntax

@t1 new Table "c1" "c2" "c3"
@t1_insights new Table "c1" "c2" "c3" "c4: math c2 * c3"

The second table includes a computed column c4, which is evaluated from each row using command expression semantics.

Example

@t1 new Table "c1" "c2" "c3"
@row1 t1.upsert "x" 2 5
@row2 t1.upsert "a" 3 5

@rows := $t1.data

upsert accepts values, objects, or another table. If the row includes an existing truid, it updates; otherwise it inserts. Runtime behavior is validated in tests/pipelines/tables/tableProcessingTest.mjs.

Step-by-Step Interaction

A typical table workflow begins when the script declares schema columns through new Table. The script then inserts or updates rows by calling upsert, either with positional values, objects, or table-derived records. Once source rows are present, the script can select and transfer subsets by combining predicate commands with exwipe, and it can merge the extracted rows into a second table that carries computed columns. This sequence allows one table to capture raw intake while another table captures transformed analytical output in the same reactive flow.

@testEntry macro item
    @c1 := $item.c1
    @res if [ assert $c1 == "a" ] then true else false
    return $res
end

@t1_newData new Table "c1" "c2" "c3"
@t1_insights new Table "c1" "c2" "c3" "c4: math c2 * c3"
@picked t1_newData.exwipe testEntry
t1_insights.upsert $picked

exwipe builds a new table from rows that satisfy a predicate command and clears them from the source table. This pattern is used in the table processing test pipeline.

Runtime Role Notes

@table new Table from message
table.upsert "Jhon" "Hello world"
@rows := $table.data

The Table type acts as a stateful row container that still remains compatible with variable-level reactivity. Field-style access through $table.data uses chain-alias resolution, so scripts can expose raw row arrays as normal variables and feed them into macros, predicates, export logic, or external integration code.