SQLlyTemplating language
○ plannedDescribe a transformation once, then let SQLly apply it across the columns that need it.
Repeating the same transformation across thirty columns is a fine way to lose an afternoon. A templating language lets you describe the change once and apply it consistently, keeping result shaping readable and repeatable.
What exists today
A single-column version already ships, and it is the seed this grows from. Right-click a column header, choose Set Formatting Override, and the picker offers:
- Template - a string with a
{value}placeholder.https://crm/customer/{value}turns an id column into something you can read at a glance;{{and}}give you literal braces. - JSON path - pull one field out of a JSON column into the grid cell, with a practical subset of JSONPath:
$,.name,[0], and quoted keys. A malformed document or a path that does not resolve leaves the cell alone rather than showing an error where data should be. - Number style - the numeric presentations described under formatting.
Each choice is written into the query as a -- sqlly format:
directive, so it travels with the file and reapplies itself on the next run.
What templating adds
The planned language closes the gap between “one column” and “the thirty columns that need the same treatment”:
- Apply by pattern - every column whose name ends in
_id, or every column of a given type, rather than one right-click at a time. - Named, reusable transforms - define “our order-id link” once and refer to it, instead of pasting the same template string into a dozen queries.
- Composition - extract, then format, then wrap, as one described pipeline.
UPDATE would write. Exports get a choice of formatted or raw values, so a transformation for reading cannot quietly become a transformation of your data.Planned. The formatter model, the directive syntax it would extend, and the single-column Template and JSON-path formatters are all shipping today - this is the multi-column layer over them.