Skip to main content

The V2 Editor

When you open a Node built on a V2 node type, the mapping grid is replaced with a SQL-first editing experience. This page explains each part of the interface and how it connects to your .sql file.

Build Settings​

When creating a Node, you'll have the option of creating a v1 Node or v2 Node. You'll also be able to see the type of other existing Nodes.

SQL Editor​

The center panel is a SQL editor where you write your SELECT statement. The Node is stored as a .sql file. The file name combines the storage location and Node name, for example WORK-STG_CUSTOMERS.sql.

The first two lines of every V2 Node file are reserved annotations that Coalesce manages automatically:

@id("1d181c4d-ac7d-4721-bc39-5ac6be21ac79")
@nodeType("10")
Reserved header annotations

Do not edit @id or @nodeType. @id identifies the Node. Changing it breaks the Node's identity, version control history, and references to it. @nodeType must map to a valid node type ID in your Workspace. Change it only when you are intentionally pointing the Node at a different valid node type.

Below the reserved annotations, you add your SQL: CTEs, the final SELECT, and any inline annotations for configuration:

@id("...")
@nodeType("...")
@materializationType("table")

WITH source_data AS (
    SELECT
        C_CUSTKEY,
        TRIM(C_NAME) AS C_NAME,
        TRIM(C_ADDRESS) AS C_ADDRESS
    FROM {{ ref('TARGET', 'STG_CUSTOMER') }}
)

SELECT
    C_CUSTKEY AS customer_key @isPrimaryKey,
    C_NAME AS customer_name @isChangeTracking @notNull,
    C_ADDRESS AS customer_address @isChangeTracking @isUnique,
    C_NATIONKEY AS nation_key @foreignKey('DIM_NATION'),
    C_ACCTBAL::DECIMAL(12,2) AS account_balance @isChangeTracking,
    C_MKTSEGMENT AS market_segment
FROM source_data

Node-level annotations such as @materializationType("table") go before the SELECT. Column-level annotations such as @isPrimaryKey, @isChangeTracking, and @notNull go directly after the column expression in the SELECT list.

For every reserved name, quoting rule, and template hook, see the SQL Annotations Reference.

Config Panel​

On V1 Nodes, the Config tab holds dropdowns, toggles, and text fields for materialization, insert strategy, preSQL and postSQL, and other settings.

On V2 Nodes, those settings live in the SQL file as annotations. The Config tab shows only the Storage Location, meaning the target database and schema where this Node deploys.

alt text
caption text
alt text
caption text

Column Grid​

Open the Columns tab next to Config on the right to see the columns Coalesce inferred from your SELECT clause. Each selected column appears with its name and data type.

The column grid is read-only. Your SQL is the source of truth. To add, remove, or rename a column, edit the SELECT statement.

Each row includes a Lineage control, shown as an eye icon, for opening column-level lineage.

UNKNOWN data types

If a column's data type shows as UNKNOWN, Coalesce could not infer the type from the expression. Add an explicit cast in your SQL, for example CAST(value AS DECIMAL(12,2)) or value::TIMESTAMP_NTZ.

Column Lineage​

Click the eye icon on any column in the grid to open the column lineage view. It shows how a column flows from its source through CTEs to the final SELECT.

For example, for C_NAME in the sample above, lineage can show how values move through each CTE step, from the upstream column through any functions such as TRIM, then into the final projection.

Column lineage behaves the same as for other Coalesce Nodes. For a V2 Node, the parser rebuilds the path from your CTE chain instead of from per-column transforms in the mapping grid.

Code and Preview Pane​

The collapsible pane at the bottom still exposes compiled SQL and run output just like v1 Nodes.

What's Next?​