Problem
The sidebar puts every database object into one mixed list under a single "Tables" section (SidebarView.swift:187). Tables and views are distinguished only by icon (eye vs tablecells) and color (purple vs blue) on each row (TableRowView.swift:13-47). Materialized views, foreign tables, procedures, and functions don't appear at all.
Users coming from DBeaver, DataGrip, or pgAdmin expect a hierarchical sidebar where each object kind is its own collapsible group. Quote from recent user feedback: "I prefer the way DBeaver separates views and tables etc."
Proposed change
Replace the single Section(isExpanded: $viewModel.isTablesExpanded) with one section per object kind, in this order:
- Tables
- Views
- Materialized Views (Postgres, others that support them)
- Foreign Tables (Postgres)
- Procedures
- Functions
Each section is collapsed by default to match DBeaver. Persist expansion state per connection alongside the existing isTablesExpanded flag (e.g. isViewsExpanded, isProceduresExpanded, etc.).
Tables section keeps its current row UI. The other sections render the same TableRow for table-like entities; procedures and functions need a thinner row variant once driver support lands.
Implementation notes
TableInfo.TableType (Models/Query/QueryResult.swift:81) already distinguishes .table and .view. Add cases for .materializedView and .foreignTable. Drivers that don't support them keep returning .table / .view.- Procedures and functions are not currently fetched by any driver. Add
fetchProcedures() and fetchFunctions() to PluginDatabaseDriver with default empty implementations, then bridge through PluginDriverAdapter. This is a PluginKit ABI change, so bump currentPluginKitVersion in PluginManager.swift and TableProPluginKitVersion in every plugin's Info.plist.
- Sections render conditionally: hide empty sections rather than showing them empty. SQLite has no procedures/functions, so those sections are hidden for SQLite connections. Redis is unaffected; its
Keys section stays as-is.
- Search/filter (
filteredTables) needs to apply across all sections.
- The right-click "Show All Tables" command needs an equivalent for each section.
Out of scope
A fully unified hierarchy (connections → databases → schemas → tables → object kinds in one tree) is tracked in #139. This issue is the smaller change of grouping the object types within the existing per-database sidebar.
Related
Problem
The sidebar puts every database object into one mixed list under a single "Tables" section (
SidebarView.swift:187). Tables and views are distinguished only by icon (eye vs tablecells) and color (purple vs blue) on each row (TableRowView.swift:13-47). Materialized views, foreign tables, procedures, and functions don't appear at all.Users coming from DBeaver, DataGrip, or pgAdmin expect a hierarchical sidebar where each object kind is its own collapsible group. Quote from recent user feedback: "I prefer the way DBeaver separates views and tables etc."
Proposed change
Replace the single
Section(isExpanded: $viewModel.isTablesExpanded)with one section per object kind, in this order:Each section is collapsed by default to match DBeaver. Persist expansion state per connection alongside the existing
isTablesExpandedflag (e.g.isViewsExpanded,isProceduresExpanded, etc.).Tables section keeps its current row UI. The other sections render the same
TableRowfor table-like entities; procedures and functions need a thinner row variant once driver support lands.Implementation notes
TableInfo.TableType(Models/Query/QueryResult.swift:81) already distinguishes.tableand.view. Add cases for.materializedViewand.foreignTable. Drivers that don't support them keep returning.table/.view.fetchProcedures()andfetchFunctions()toPluginDatabaseDriverwith default empty implementations, then bridge throughPluginDriverAdapter. This is a PluginKit ABI change, so bumpcurrentPluginKitVersioninPluginManager.swiftandTableProPluginKitVersionin every plugin'sInfo.plist.Keyssection stays as-is.filteredTables) needs to apply across all sections.Out of scope
A fully unified hierarchy (connections → databases → schemas → tables → object kinds in one tree) is tracked in #139. This issue is the smaller change of grouping the object types within the existing per-database sidebar.
Related