By default, no column yet, and so nothing typed
Optionalrest: JsonObjectReadonlyidUnique within the query and shown to users, e.g. filter101
ReadonlykeyAssigned at construction from a monotonic sequence: the node's identity for change detection
ReadonlyrestThe keys of the node's saved JSON that this version does not know, kept so a re-save writes them back (PLAN §10.3); edits keep them too
Whether edits may change which nodes feed this one. Not for a node whose port semantics are unknown, such as an Unknown node.
Whether the node takes rows by their order, as a Limit does: the emitter then writes its input's order as a sort just before it (PLAN §11.4)
Labels for the input ports, shown on the edges that feed them
The named input slots, in order: none for a source, one for a unary transform, two for a binary one
The type discriminator, e.g. filter
The typing, if it is for this input schema and these columns; else nothing yet
As the spec says: Extend with "x", "y"
Without the names the user gave: Extend with 2 columns
Each column's first problem that needs no engine, by index, undefined
for a column without one: a name, valid, no input column's and no earlier
column's (compared as databases that ignore case compare them), and an
expression, a lambda of one row, with no backslash in a startsWith,
endsWith or contains literal (as a Filter by Expression's, PLAN
§11.14). The editor checks these before it asks the engine to type the
columns.
Each column's problem with the type the engine gave it, by index: a primitive or an enumeration, never a type Cube doesn't know, such as Any
Whether the node has none of the settings it needs yet, e.g. a Join with no key pair: the canvas shows it as not set, not by its description
The input's columns, then one per new column, in listed order, typed as
the engine typed it and nullable: an expression over an empty value is
empty in SQL, though the engine types it never empty after toOne()
(PLAN §11.7); undefined when invalid
Checks, in order: there are columns; then each column, every one
reported, stopping at its first problem: a name, valid, no input
column's and no earlier column's (compared as databases that ignore case
compare them), and an expression, a lambda of one row. Then the typing:
pending until the engine has typed these columns for this input
(ERR_TYPING), the engine's problem when it couldn't, then each type a
primitive or an enumeration.
Optionalerrors: string[]A new extend with the same id, and these columns; the typing is kept, and is current only if they type the same
The node to keep once its two inputs swap ports: by default this node. A node whose settings name its inputs by side, such as a Join's key columns, returns a new node (same id) with those settings swapped too.
A new extend with the same id and columns, and this typing
Adds columns computed by expressions (spec §7.14, PLAN §11.7), each a lambda of one row that may use the input's columns and the columns listed before it. The engine types them, against the cube's model; until it has, for this input and these expressions, the node waits (
ERR_TYPING). Every input column and row stays, in the input's order.