Column modifiers

Whatever a query returns — a Table panel’s own rows, or a drill-down query’s result on any other panel type — goes through the same “Columns” list in the editor’s Display options: one row per detected column, with a rename field, a type override, and a gear-icon menu. This page walks through each part of that list with real screenshots, using one example query that returns every column type at once:

SELECT  event_class AS type,  timestamp AS occurred,  JSONExtractFloat(metadata, 'receipt_total') AS receipt_total,  metadata AS details,  JSONExtractRaw(metadata, 'items') AS itemsFROM chomper.eventsWHERE event_class = 'sale'ORDER BY timestamp DESCLIMIT 30

Five columns, five different resolved types: type auto-detects as string, occurred as datetime, receipt_total as number, details (a JSON object) as json, and items (a JSON array of objects) as table.

Renaming and overriding the type

Each column’s row starts with its raw key from the query (shown in monospace), a text field to give it a friendlier label on the live panel, and a dropdown defaulting to “Auto (…)” — whatever type was detected from the sample rows. Overriding it changes how the column sorts, how its filter row behaves, and which options the gear menu itself offers, since those all depend on the resolved type, not the raw SQL type.

Hide column

Every column’s gear menu opens with a Hide column toggle — it drops that column from the rendered table entirely, on the live panel and in this same preview, without touching the query. Useful for a column a query needs internally (say, joining or sorting) but that isn’t worth showing.

Gear menu on the “type” column — Hide column and Show filter row, the two options every column type gets.

Show filter row: a different filter per type

Turning on Show filter row adds a small filter control under that column’s header. What it looks like depends on the column’s resolved type:

• String — a plain text box, matching case-insensitively anywhere in the value.
• Number — a Min/Max pair; either side can be left blank for an open-ended range.
• Datetime — the same time range picker used for the dashboard’s own range, with a small × button to clear it once set.
• JSON / Table — a regex box, matched against the column’s entire raw JSON rather than a single displayed value — the only way to search inside a nested structure.

All four are independent and stack: filtering is an AND across every column with an active filter, live on top of whatever sort is applied.

All four filter types side by side: substring search on type, a date range on occurred, Min/Max on receipt_total, and Regex on JSON for both details and items.

JSON columns: Pretty vs. Compact

A json-typed column never dumps raw JSON text into a table cell — it renders as a short summary chip ({11 keys}, in this example) that opens the full value in a popover on click. The column’s own gear menu picks how that popover formats the value:

Gear menu on the “details” column — a json-typed column additionally gets a Show as: Pretty/Compact choice.

Pretty (the default) indents nested objects and arrays onto their own lines — worth it the moment a value has more than two or three keys, since a flat wall of text gets hard to scan:

The “details” column’s popover in Pretty mode — indented, one key per line.

Compact renders the same value as a single-line JSON.stringify — better once a value is short enough that the extra height of Pretty mode isn’t buying anything:

The same column switched to Compact — one line, easier to scan a list of short values quickly.

Table columns: nested table vs. Convenient JSON

A table-typed column holds a JSON array rather than a single object — typically one row’s worth of line items, tags, or any other one-to-many field. Its chip ([4 items], here) opens a popover with its own Show as choice:

Table (the default) renders an array of objects as its own small nested table — the union of keys across every element becomes the column set, so elements don’t all need to match shape exactly:

The “items” column’s popover in Table mode — name/qty/price rendered as a real nested table, not raw JSON.

Convenient JSON falls back to the same indented view json columns use, for when a raw look at the array is more useful than a table — e.g. copying the exact JSON out, or an array whose elements don’t share enough structure to table cleanly:

The same “items” column switched to Convenient JSON — indented array, same formatting as a json column’s Pretty mode.

Note. None of the above touches the underlying query — renaming, hiding, filtering, and display mode are all purely how the same result set is shown. They’re safe to change freely while getting a panel’s columns right, and they apply identically whether the rows came from a Table panel’s own query or from another panel type’s drill-down query.