dbx/docs/content/docs/data-grid.mdx

146 lines
6.2 KiB
Plaintext

---
title: Data Grid
description: Browse, filter, edit, preview SQL, and export table data in DBX.
---
The data grid displays query results and table data. It is designed for two common workflows: inspecting data quickly and making small, reviewable edits.
## Browse Data
DBX uses virtual scrolling, rendering only the rows visible on screen. Large tables remain responsive because the grid does not render every row at once.
Common browsing actions:
- Drag column borders to resize columns
- Double-click a column border to auto-fit width
- Click column headers to sort
- Use row numbers to locate records
- Open cell details for long text, JSON, or other complex values
## Filter and Sort
| Feature | Best For |
|---|---|
| Search | Finding rows in the current result set |
| WHERE | Database-level filtering for large tables or precise conditions |
| ORDER BY | Database-level ordering for reproducible results |
<Callout type="info">
For large tables, prefer `WHERE` and `ORDER BY`. They run in the database and are usually more reliable than client-side search.
</Callout>
## Inline Editing
You can edit data directly in the grid:
- **Update a cell**: double-click a cell and edit its value
- **Insert a row**: add a pending row in the grid
- **Delete rows**: select rows and mark them for deletion
- **Set NULL**: explicitly write `NULL` from the cell detail panel
All changes are staged locally first. Before saving, DBX shows the SQL it is about to execute.
## When Editing Is Available
Editing is available when DBX can identify the target table and enough key information to generate reviewable `UPDATE`, `INSERT`, or `DELETE` statements. Simple table browsing is usually editable. Ad-hoc joins, aggregates, expressions, or result sets without usable keys are treated as read-only.
| Result Type | Typical Behavior |
|---|---|
| Opened table data | Editable when the database and table support edits |
| Simple `SELECT * FROM table` | Often editable if primary key or row identity is available |
| Joins, aggregates, computed columns | Read-only result set |
| Redis or MongoDB views | Use their dedicated editors instead of relational row SQL |
## SQL Preview
<Callout type="warn">
Edits are not written to the database immediately. Before saving, review the SQL preview carefully, especially on production connections.
</Callout>
The preview shows `UPDATE`, `INSERT`, or `DELETE` statements. Use it to confirm:
- Update conditions target the intended rows
- Inserted rows contain the expected fields
- Delete operations match the expected records
- `NULL`, empty strings, and default values are handled correctly
If the preview looks too broad, cancel the save and narrow the filter or selection first.
## Cell Details
Click a cell to open the detail panel. It is useful for values that are awkward to edit directly inside a table:
- Long text
- JSON
- SQL fragments
- Multi-line content
- Fields that should be explicitly set to `NULL`
## Transpose View
Toggle the transpose view to swap rows and columns. This is useful when:
- A table has many columns but few rows
- You want to compare column metadata (types, defaults, nullable flags) side by side
- You are inspecting a single row with wide columns
The transpose view preserves all grid features: sorting, filtering, editing, and export work the same way.
## Column Formatters
Custom column formatters let you control how specific column values are displayed:
- **Datetime formatting**: Choose a display format for date and time columns
- **JSON path extraction**: Extract a specific field from JSON/JSONB columns using a JSONPath expression
- **Value masking**: Hide or partially mask sensitive values
- **Custom templates**: Define your own display template for a column
Configure formatters from the column header menu. Formatters only affect display — they do not change the underlying data.
## Cell Detail Editor
The cell detail panel provides a full editor for individual cell values:
- **Value editor**: Edit cell content in a larger text area with syntax highlighting for JSON and SQL
- **Set NULL**: Explicitly write NULL to a cell
- **Image preview**: When a cell contains an image URL, the detail panel shows a rendered preview
- **Temporal editor**: Date and time cells use a dedicated date/time picker
## Multi-Row Operations
Select multiple rows to perform batch operations:
- **Batch clone**: Duplicate multiple rows at once
- **Batch delete**: Mark multiple rows for deletion in one action
- **Batch copy**: Copy multiple rows as TSV, CSV, JSON, Markdown, or INSERT statements
- **Copy as INSERT**: Generate a single `INSERT` statement with multiple value rows
- **Copy as UPDATE**: Generate `UPDATE` statements for selected rows
- **Copy without primary keys**: Generate INSERT statements that exclude auto-increment primary keys
## Header Controls
Column headers provide quick access to actions:
- **Sort**: Click to toggle ascending, descending, or clear sort. Right-click for context menu with sort options.
- **Column visibility**: Show or hide columns from a filterable checklist
- **Local column filter**: Filter values within the current result set by checking specific values
- **Compact mode**: When enabled in Settings, header actions (sort, format, filter) collapse into a single dropdown menu, giving column names more space
- **Compact filter builder**: Build complex client-side filters with multiple conditions in a compact UI
## Export and Copy
| Format | Use Case |
|---|---|
| CSV | Excel, Numbers, or spreadsheet tools |
| JSON | Scripts, API debugging, or programmatic processing |
| Markdown | Issues, PRs, documentation, or chat |
| INSERT | Copy selected rows as executable `INSERT` statements (single or batched) |
| UPDATE | Copy selected rows as executable `UPDATE` statements |
| XLSX | Export directly to Excel format from the table context menu |
Before exporting, check the active filters and sort order so the exported data matches what you expect.
## Pagination And Large Results
DBX can page result sets and keep large grids responsive with virtual scrolling. For large tables, prefer database-side `WHERE` and `ORDER BY` clauses instead of relying only on client search, because the database can use indexes and return a smaller result set. Page size is configurable and persists across sessions.