Skip to content

Tables and Safe Editing

dlagoCalimaco edited this page Jul 23, 2026 · 4 revisions

Tables and Safe Editing

The table viewer provides server-side pagination, multi-column sorting, parameterized filters, search, column metadata, indexes, foreign keys and DDL.

Select a cell and open Table filters to prefill the builder with that column and value. The cell context menu also provides compact actions to filter by the value, exclude it or continue in the full filter builder. NULL values use IS NULL and IS NOT NULL automatically.

The table header stays deliberately compact. Its first row identifies the active table and switches between Data, Structure, Indexes, Foreign keys and DDL. Data actions, pending changes, search, filtering and refresh share a second row only while the Data section is active.

Query results remain read-only by default. For an editable result, double-click a cell or enable edit mode explicitly; LakeDB then applies the same identity and safety checks used by a normal table view. A SELECT with no rows still opens an empty grid with its column headers.

Visual table design

Create a table from the Tables folder or open Modify table from an existing table's context menu. The designer keeps the visual model and generated SQL together:

  • Add, remove and reorder columns in a compact resizable grid.
  • Choose data type, length or enum values, default, nullability, primary key, unsigned, auto increment, on-update expression and comment.
  • Build ordered indexes, foreign keys and check constraints.
  • Review the exact create/alter statements in SQL preview before applying them.

Procedures, functions, triggers and events open directly as their stored source definition.

Buffered changes

Edit, insert, duplicate or mark rows for deletion. Changes stay in a local buffer until you select Apply, so you can inspect the summary and generated SQL or discard the whole batch.

Pending rows are deliberately easy to distinguish: edited rows are yellow, new rows are green and rows marked for deletion are red. A duplicated row initially appears directly below its source; after Apply, the database may place it elsewhere according to generated keys and the active sort.

Large and structured values

Double-click a large editable cell to open the full-value editor. Choose Plain text, JSON or HTML, then use Check before saving. Valid JSON and HTML show a positive status; malformed structured content stays open with a precise error. HTML is validated as source text and is never rendered or executed by LakeDB.

LakeDB also matches common MySQL types with appropriate inline controls:

  • DATE, DATETIME and TIMESTAMP use native date and date-time pickers.
  • Normal clock values in TIME use a time picker; negative or greater-than-24-hour durations remain text to preserve MySQL semantics.
  • Numeric columns use numeric input, boolean-like columns use a true/false selector and ENUM uses its declared options.
  • Clearing a nullable typed value writes NULL.
  • BLOB, binary and geometry summaries stay read-only because their complete value is not materialized in the renderer.

Safe row identity

Edits can be applied only when LakeDB can identify exactly one row through a primary key or a complete UNIQUE index without nullable columns. If the server rejects a value or the row cannot be changed safely, LakeDB keeps the pending edit and exposes the generated SQL/error for review instead of silently discarding it.

Conflict detection and rollback

LakeDB starts a transaction, locks each target row and compares its original values. If another user changed it, or a mutation affects anything other than one row, the complete batch is rolled back and the local buffer remains available for review.

Read-only connections block writes and DDL. Dangerous production changes require typing PRODUCTION (legacy Spanish installations also accept PRODUCCION).

Clone this wiki locally