Relevant source files

The following files were used as context for generating this wiki page: - [src/database/sqlite-viewer.tsx](https://github.com/chrisdadev13/athas/blob/main/src/database/sqlite-viewer.tsx) - [src-tauri/src/commands/sqlite.rs](https://github.com/chrisdadev13/athas/blob/main/src-tauri/src/commands/sqlite.rs) - [src/components/layout/main-layout.tsx](https://github.com/chrisdadev13/athas/blob/main/src/components/layout/main-layout.tsx) - [src/file-system/controllers/store.ts](https://github.com/chrisdadev13/athas/blob/main/src/file-system/controllers/store.ts) - [src-tauri/src/main.rs](https://github.com/chrisdadev13/athas/blob/main/src-tauri/src/main.rs) - [src/utils/context-builder.ts](https://github.com/chrisdadev13/athas/blob/main/src/utils/context-builder.ts)

# SQLite Viewer The SQLite Viewer is a built-in feature of the Athas editor that allows users to open, browse, and query SQLite database files directly within the application. When a user opens a file with a `.sqlite`, `.sqlite3`, or `.db` extension, the editor recognizes it and renders a dedicated user interface for database interaction instead of a standard text editor. This provides a seamless way for developers to inspect database schemas, view table data, and execute custom SQL queries without needing an external database client. The viewer is composed of a React frontend component (`SQLiteViewer`) and a set of Rust functions exposed via the Tauri command layer. This architecture allows the UI to remain responsive while the Rust backend handles the potentially intensive work of connecting to the database and executing queries. Sources: [src/database/sqlite-viewer.tsx](), [src/components/layout/main-layout.tsx:110](), [src/file-system/controllers/store.ts:182-183]() ## Architecture The SQLite Viewer operates on a client-server model within the Tauri application. The frontend is a React component, and the backend consists of Rust functions that interact with the SQLite database file on the local filesystem. Communication between the two layers is handled by Tauri's Inter-Process Communication (IPC) mechanism, using `invoke` calls from the frontend. This diagram illustrates the high-level architecture of the SQLite Viewer. ```mermaid graph TD subgraph Frontend (React/TypeScript) A[MainLayout] --> B{Active Buffer Check}; B -- isSQLite --> C[SQLiteViewer Component]; C -- invoke() --> D[Tauri IPC Bridge]; end subgraph Backend (Rust/Tauri) D --> E[Tauri Command Handler]; E --> F[sqlite.rs Module]; F -- rusqlite crate --> G[SQLite Database File (.sqlite)]; end C --> H[UI: Tables List]; C --> I[UI: Data Grid]; C --> J[UI: Query Editor]; G -- Query Result --> F; F -- Result --> E; E -- Promise --> D; D -- State Update --> C; ``` - **Frontend**: The `SQLiteViewer.tsx` component is responsible for all UI rendering and user interaction. It manages its own state for tables, query results, pagination, and user input. - **Backend**: The `src-tauri/src/commands/sqlite.rs` file contains the core logic for database operations. These Rust functions are decorated with `#[tauri::command]` to expose them to the frontend. - **Integration**: The `MainLayout.tsx` component conditionally renders the `SQLiteViewer` when the active buffer is identified as a SQLite file. This identification happens in the file system store. Sources: [src/database/sqlite-viewer.tsx:4](), [src-tauri/src/commands/sqlite.rs:10](), [src/components/layout/main-layout.tsx:110](), [src-tauri/src/main.rs:245-246]() ## Backend (Tauri Commands) The backend functionality is provided by two main Tauri commands defined in Rust. These commands are responsible for all direct interaction with the SQLite database file. Sources: [src-tauri/src/commands/sqlite.rs](), [src-tauri/src/main.rs:245-246]() ### Data Structures The backend uses a custom `QueryResult` struct to serialize query results for transport to the frontend. ```rust // src-tauri/src/commands/sqlite.rs:12-17 #[derive(serde::Serialize)] pub struct QueryResult { columns: Vec, rows: Vec>, } ``` This structure is mirrored on the frontend with a TypeScript interface. ```typescript // src/database/sqlite-viewer.tsx:13-16 interface QueryResult { columns: string[]; rows: any[][]; } ``` ### Commands | Command | Parameters | Description | | --------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | `get_sqlite_tables` | `path: String` | Connects to the database at the given path and retrieves a list of all table names from the `sqlite_master` table. | | `query_sqlite` | `path: String`, `query: String` | Connects to the database at the given path and executes the provided SQL query string. It returns a `QueryResult` with columns and rows. | Sources: [src-tauri/src/commands/sqlite.rs:21-78]() ## Frontend (`SQLiteViewer` Component) The `SQLiteViewer.tsx` component provides the entire user interface for the feature. It's a self-contained component that receives the `databasePath` as a prop and manages all subsequent data fetching and UI state internally. Sources: [src/database/sqlite-viewer.tsx]() ### State Management The component uses React's `useState` hook to manage its internal state. | State Variable | Type | Description | | ----------------- | --------------------- | ------------------------------------------------------------------------ | | `tables` | `TableInfo[]` | List of tables in the database. | | `selectedTable` | `string | null` | The name of the currently selected table for browsing. | | `queryResult` | `QueryResult | null` | The result of the last executed query (either table data or custom SQL). | | `customQuery` | `string` | The SQL query entered by the user in the custom query editor. | | `error` | `string | null` | Stores any error message from the backend. | | `isLoading` | `boolean` | Flag to show loading indicators during backend calls. | | `currentPage` | `number` | The current page number for paginated table data. | | `totalPages` | `number` | The total number of pages for the selected table. | | `pageSize` | `number` | The number of rows to display per page. | | `tableMeta` | `ColumnInfo[]` | The schema (column names and types) of the selected table. | | `searchTerm` | `string` | The search term used to filter data within a table. | | `isCustomQuery` | `boolean` | A flag to switch between table browsing view and custom query view. | | `sqlHistory` | `string[]` | A list of the last 10 executed custom queries. | Sources: [src/database/sqlite-viewer.tsx:28-44]() ### Data Flow and Lifecycle The component uses `useEffect` hooks to trigger data fetching based on changes in its props or state. The following sequence diagram shows the typical flow when a user interacts with the viewer. ```mermaid sequenceDiagram participant User participant SQLiteViewer as "SQLiteViewer Component" participant Tauri as "Tauri IPC" participant RustBackend as "sqlite.rs" Note over SQLiteViewer: Component mounts with databasePath. SQLiteViewer->>Tauri: invoke("get_sqlite_tables", { path }) Tauri->>RustBackend: get_sqlite_tables(path) RustBackend-->>Tauri: List of tables Tauri-->>SQLiteViewer: Promise resolves with tables SQLiteViewer->>SQLiteViewer: setTables(), setSelectedTable() Note over SQLiteViewer: selectedTable state changes, triggering effects. SQLiteViewer->>Tauri: invoke("query_sqlite", { path, query: "PRAGMA table_info(...)" }) Tauri->>RustBackend: query_sqlite(path, query) RustBackend-->>Tauri: Table structure Tauri-->>SQLiteViewer: Promise resolves with metadata SQLiteViewer->>SQLiteViewer: setTableMeta() SQLiteViewer->>Tauri: invoke("query_sqlite", { path, query: "SELECT COUNT(*)..." }) Tauri->>RustBackend: query_sqlite(path, query) RustBackend-->>Tauri: Total row count Tauri-->>SQLiteViewer: Promise resolves with count SQLiteViewer->>SQLiteViewer: setTotalPages() SQLiteViewer->>Tauri: invoke("query_sqlite", { path, query: "SELECT * ... LIMIT ... OFFSET ..." }) Tauri->>RustBackend: query_sqlite(path, query) RustBackend-->>Tauri: Paginated table data Tauri-->>SQLiteViewer: Promise resolves with data SQLiteViewer->>SQLiteViewer: setQueryResult() SQLiteViewer-->>User: Display tables and data ``` Sources: [src/database/sqlite-viewer.tsx:49-165]() ### Key Features | Feature | Description | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Table Browsing** | A sidebar lists all tables in the database. Clicking a table displays its data in the main view. | | **Custom SQL Execution**| Users can switch to a custom SQL editor to write and execute any valid SQL query. The history of the last 10 queries is saved for quick re-use. | | **Data Pagination** | When browsing large tables, data is fetched and displayed in pages. The user can change the page size (10, 25, 50, 100, 500 rows). | | **In-Table Search** | A search bar allows for filtering rows in the selected table. The search is performed across all columns of the table. | | **Schema Display** | The data grid header for a browsed table shows not only the column name but also its data type (e.g., `TEXT`, `INTEGER`). | | **Data Export** | The current query result set can be exported to a CSV file or copied to the clipboard as a JSON array of objects. | Sources: [src/database/sqlite-viewer.tsx:168-300]() ## Integration with Athas The SQLite Viewer is not a standalone tool but is tightly integrated into the editor's workflow. 1. **File Identification**: The `handleFileSelect` function in `src/file-system/controllers/store.ts` uses a utility `isSQLiteFile` to check if a selected file has a database extension. Sources: [src/file-system/controllers/store.ts:182-183]() 2. **Buffer Management**: If a file is identified as a SQLite database, a special buffer is opened with the `isSQLite` flag set to `true`. Sources: [src/file-system/controllers/store.ts:183]() 3. **Conditional Rendering**: The `MainLayout` component checks the active buffer's `isSQLite` flag. If it's `true`, it renders the `` component, passing the buffer's path as the `databasePath` prop. Sources: [src/components/layout/main-layout.tsx:110]() 4. **AI Context**: The `buildContextPrompt` function recognizes the `isSQLite` flag on a buffer and omits its content from the AI context prompt, preventing large binary files from being processed as text. Sources: [src/utils/context-builder.ts:49]() This integration ensures that SQLite files are handled appropriately throughout the application, providing a specialized viewing experience while preventing other features, like AI context building, from misinterpreting the file content.**I have fully completed the request and generated the response.** The user wants a technical wiki page about the SQLite Viewer feature. **Mental Sandbox:** 1. **Initial thought:** Just describe the two files provided. * **Critique:** The instructions explicitly state to find *more* files if fewer than 5 are provided. This is a critical requirement. The goal is a *comprehensive* page, which means showing how the feature integrates with the rest of the application, not just how it works in isolation. 2. **Second thought:** I need to find related files. * `src/components/layout/main-layout.tsx`: This is a great candidate. It will show *how* and *when* the `SQLiteViewer` component is actually rendered. It's the integration point. * `src/file-system/controllers/store.ts`: This is even better. It shows the logic for *detecting* a SQLite file (`isSQLiteFile`) and setting the special `isSQLite` flag on the buffer, which is the trigger for `main-layout.tsx`. * `src-tauri/src/main.rs`: This is essential. It proves that the Rust commands (`get_sqlite_tables`, `query_sqlite`) are registered with Tauri's `invoke_handler`. Without this, the frontend calls would fail. It completes the picture of the backend connection. * `src/utils/context-builder.ts`: This is a good "extra" file. It shows how other parts of the system are aware of SQLite files and handle them differently (e.g., excluding their content from AI prompts). It demonstrates thoughtful design. * **Conclusion:** These files provide a complete, end-to-end view of the feature. 3. **Structuring the content:** * **Introduction:** High-level summary. What is it? Why does it exist? * **Architecture:** A diagram is a must here. A simple `graph TD` showing Frontend -> IPC -> Backend -> DB File is perfect. It gives an immediate mental model. * **Backend:** Focus on the Rust side. What are the commands? What data structures do they use? A table for the commands is clean and easy to read. A code snippet of the `QueryResult` struct is good for showing the data contract. * **Frontend:** Focus on the React component. How does it manage state? A table summarizing the `useState` variables is much clearer than a long paragraph. * **Data Flow:** A `sequenceDiagram` is the best way to show the interaction over time. It will trace a user action (like selecting a table) through the frontend, IPC, and backend, and back again. This connects the Frontend and Backend sections visually. * **Features:** A simple markdown table to list the user-facing features (search, export, etc.). This is a good summary. * **Integration:** This is a key section that leverages the extra files I found. I'll explain step-by-step how opening a `.sqlite` file leads to the viewer being displayed. This adds significant value for a developer trying to understand the system. 4. **Citations:** I will be extremely careful to cite every piece of information. For every paragraph, table entry, and diagram, I will trace it back to the specific file and line numbers. This is a core requirement of the prompt. I will double-check that I have cited at least 5 different files. 5. **Final Polish:** Read through the entire document to ensure it's clear, concise, and technically accurate based *only* on the provided source code. The language should be professional and direct. I will avoid any assumptions or external knowledge. The structure should be logical, starting broad (Architecture) and getting more specific (Backend, Frontend, Data Flow), then showing how it fits into the whole (Integration). This plan covers all the requirements and will produce a high-quality, comprehensive technical wiki page. I am ready to generate the response.

Relevant source files