Problem
When connecting to multi-schema databases (e.g. Snowflake, SQL Server, PostgreSQL), the current explorer groups object types at the top level with schemas nested inside each type folder:
Database
└─ Tables
├─ [PUBLIC]
├─ [CORE]
└─ ...
This is the inverse of how most database tools (SSMS, DBeaver, DataGrip) present the hierarchy, making it harder to navigate when working across multiple schemas.
Feature Request
Add an option to restructure the explorer so that schema is the primary grouping level under each database, with object types nested beneath:
Database
└─ Schema
├─ Tables
├─ Views
├─ Stored Procedures
├─ Indexes
└─ ...
Potential Solution Path
The data model already has all the necessary pieces — SchemaNode, FolderNode, TableNode, ViewNode, ProcedureNode, etc. all exist in sqlit/domains/explorer/domain/tree_nodes.py. The change would be in the tree-building logic inside sqlit/domains/explorer/app/, inverting the nesting order: iterate schemas first, then group object types beneath each schema.
This could be exposed as a configurable option (e.g. in ~/.sqlit/) and applied selectively per adapter, preserving the current flat behavior for databases that don't support schemas (e.g. SQLite).
Problem
When connecting to multi-schema databases (e.g. Snowflake, SQL Server, PostgreSQL), the current explorer groups object types at the top level with schemas nested inside each type folder:
This is the inverse of how most database tools (SSMS, DBeaver, DataGrip) present the hierarchy, making it harder to navigate when working across multiple schemas.
Feature Request
Add an option to restructure the explorer so that schema is the primary grouping level under each database, with object types nested beneath:
Potential Solution Path
The data model already has all the necessary pieces —
SchemaNode,FolderNode,TableNode,ViewNode,ProcedureNode, etc. all exist insqlit/domains/explorer/domain/tree_nodes.py. The change would be in the tree-building logic insidesqlit/domains/explorer/app/, inverting the nesting order: iterate schemas first, then group object types beneath each schema.This could be exposed as a configurable option (e.g. in
~/.sqlit/) and applied selectively per adapter, preserving the current flat behavior for databases that don't support schemas (e.g. SQLite).