TabularisDB/tabularis

How the registry works today The plugin registry is a single static plugins/registry.json file checked into the tabularis-website repo. Each plugin is one entry, each version is one block under releases:, and every asset URL points at a GitHub Releases download on the plugin author's repo. The app reads this JSON at install time. What this means in practice: Adding a new plugin means opening a PR on the website repo. I review and merge. Shipping a new version of an existing plugin means another PR. Same flow. The plugin author has no way to publish on their own schedule. There's no "I own this plugin id" — it's whatever the JSON says. There are no download numbers. We don't know which plugins anyone uses. There's no validation beyond "the JSON parsed and I trusted the PR." This worked while the registry had three plugins and one author. It does not scale to an actual ecosystem. Where we want to go A dedicated registry platform, hosted on a subdomain of tabularis.dev, where: Plugin

I'm a backend dev. I built most of the current UI by eye, without any design background. It works, but it looks like what it is: a frontend assembled one modal at a time, with colors and spacing picked on the spot. Some examples of what I mean: the logo is a placeholder I never replaced the color palette grew organically. The CSS variables in src/index.css (bg-base, bg-elevated, text-primary, etc.) are an attempt to centralize it, but the values themselves were chosen by trial and error spacing is inconsistent across pages. You'll find p-3, p-4, p-5 on similar-looking containers depending on which file I was in that day button, input and modal styles drift between the Connection modal, the Settings page, the plugin modals and the query editor toolbar icons (lucide) get a different size or stroke depending on the component light/dark themes are kept in sync manually, so they fall out of sync What I'd like to do, eventually: a real logo, in the sizes the app actually needs (titlebar,

SQL Server driver — implementation roadmap & call for contributors Status Phase 1 is done on feat/sql-server. Clean-room tiberius + deadpool, peer to MySQL / PostgreSQL / SQLite. Not merged to main. Not in any released build. The branch squashes into main when Phase 2 closes via #149. Phase 2 (editing + TLS + composite keys) is open for contribution. Phase 3 (DDL + EXPLAIN + Azure AD) is on the roadmap. 471 Rust tests pass, zero regressions on the existing drivers. Contributors: branch off feat/sql-server, not main. Target your PR at feat/sql-server, not main. Phase 1 — done on feat/sql-server Driver registered in src-tauri/src/lib.rs, selectable from the Connection modal readonly: true manifest (INSERT / UPDATE / DELETE hidden in UI during the preview) Pool built on deadpool + a custom tiberius::Manager (src-tauri/src/drivers/sqlserver/pool.rs) Schema discovery via sys.* + INFORMATION_SCHEMA.* (tables / columns / FK / indexes / views / routines) execute_query with dialect-aware p

[Phase 2] Flip driver manifest to editing-ready (closes Phase 2) Part of the SQL Server Phase 2 epic #150. Blocked by #ISSUE_1, #ISSUE_2, #ISSUE_3, #ISSUE_4, #ISSUE_5 — should be the last PR of Phase 2. The driver isn't on main. Code lives on feat/sql-server and isn't in any release. This PR is the close-out — once it lands on feat/sql-server, the whole branch squashes into main. Once all the backend + frontend Phase 2 work has landed, this PR re-enables editing in the UI by flipping capability flags in the driver manifest. Should be a tiny diff + a thorough manual QA pass. Task Backend In src-tauri/src/drivers/sqlserver/mod.rs::SqlServerDriver::new: DriverCapabilities { // ... alter_column: false, // keep false — DDL generation is Phase 3 create_foreign_keys: false, // keep false — DDL generation is Phase 3 manage_tables: true, // was false ← change readonly: false, // was true ← change } Bump the driver version: version: "0.

[Phase 2] Frontend: DataGrid + Editor + SchemaDiagram composite-PK support Part of the SQL Server Phase 2 epic #150. Depends on #ISSUE_2 (backend CRUD) and #ISSUE_3 (FK aggregation). The driver isn't on main. Code lives on feat/sql-server and isn't in any release. Check that branch out, branch off it, target your PR at it — not at main. The whole thing squashes into main when Phase 2 closes (#149). Once the backend supports composite PKs and aggregated FKs, three React components need to carry the new identifier shape through the UI. Task 1. src/components/ui/DataGrid.tsx (≈ lines 65–84, 400–418) Add a new optional prop: pkColumns?: string[]; // composite; overrides `pkColumn` when provided When present and > 1 columns, the row-edit handlers (~ lines 400–418) must build pk_cols[] / pk_vals[] from the row instead of a single pkCol / pkVal, and pass them to the invoke calls. When pkColumns?.length === 1 or missing → legacy behaviour unchanged. 2. src/pages/Editor.tsx (≈ l