alterdb 0.2.2__tar.gz → 0.2.4__tar.gz

{alterdb-0.2.2 → alterdb-0.2.4}/CHANGELOG.md

@@ -2,6 +2,171 @@
 
 All notable changes to Alter are documented here.
 
+## [0.2.4] — 2026-03-17
+
+### Bug Fixes
+
+#### Duplicate FK constraints in migration SQL (Bug C)
+
+When a new table with a foreign key column was added on the canvas, `_migration_sql()`
+emitted the FK constraint twice: once inline inside the `CREATE TABLE` statement (via
+`_table_to_sql()`), and a second time as a standalone `ALTER TABLE … ADD CONSTRAINT`
+from the `add_relation` change handler.
+
+Fixed by collecting the names of all tables being created in the current diff into an
+`added_tables` set. The `add_relation` handler now skips emitting a separate FK
+statement for any table in that set, since the `CREATE TABLE` block already contains
+the inline reference.
+
+#### `alter canvas` crashes on fresh project with no `schema.alter` file (Bug D)
+
+Running `alter canvas` in a project that had never been initialised (no `schema.alter`
+file yet) caused `watchfiles.watch()` to raise an error because the target path did not
+exist. The traceback surfaced as an unhandled exception in the file-watcher thread,
+producing a noisy and confusing error message in the terminal.
+
+The file watcher thread now blocks on a `threading.Event` (`_file_created`) instead of
+starting immediately. The event is signalled the first time `schema.alter` is written
+(on the first Commit or Apply to Code), at which point `watchfiles.watch()` is called
+on a path that is guaranteed to exist. Before the file exists, the canvas still loads
+and works fully — changes are simply held in memory until the first commit.
+
+#### `apply_to_code` silently using stale committed schema (Bug E)
+
+When the canvas "Apply to Code" button was clicked with uncommitted staged changes
+present, `_apply_to_code_impl` read `staging.current_schema` (the last committed
+state) rather than `staging.proposed_schema` (the in-memory working state). Staged
+changes were silently discarded from the code write while they remained visible on the
+canvas, causing the model files to diverge from what the canvas showed.
+
+Two-part fix:
+
+1. **Canvas handler auto-commit** — `_handle_apply_to_code` in `canvas/server.py` now
+   calls `staging.commit()` before delegating to `_apply_to_code_impl` whenever there
+   are pending staged changes. This ensures the code write always reflects the current
+   canvas state.
+
+2. **MCP guard** — `apply_to_code()` in `mcp_server.py` now returns an early error
+   message if `staging.has_pending()` is true, asking the caller to invoke
+   `commit_changes()` first. This prevents the MCP path from silently applying a stale
+   snapshot while an in-progress edit session is underway.
+
+#### `alter import` creates spurious `app/models.py` on new projects (Bug F)
+
+`alter import schema.sql` was routing imported tables to
+`metadata.sqlmodel_module`, which defaults to `"app/models.py"`. On projects that had
+no `app/` directory, this caused `alter apply` to create `app/models.py` as a new
+file even though the project had no such layout.
+
+The import command now calls `_default_model_path(current_schema, project_root)` to
+infer the correct output file, applying the same priority logic used everywhere else
+in the codebase: most-common directory across existing tracked tables → `app/` if it
+exists → `models.py` in the project root. No phantom files are created.
+
+#### MCP server emits `PydanticJsonSchemaWarning` on startup (Bug G)
+
+The `_UNSET = object()` sentinel — used as the default for `default`, `max_length`,
+and `foreign_key` parameters in `modify_column` so that callers can pass explicit
+`None` to clear a field — caused Pydantic to emit a `PydanticJsonSchemaWarning` when
+building the JSON schema for the MCP tool at server startup. The warning was harmless
+(the sentinel works correctly at call time) but noisy.
+
+Fixed by wrapping the tool-registration loop in `_LazyMCP._init_real` with a
+`warnings.catch_warnings()` context manager that suppresses
+`"Default value.*is not JSON serializable"` messages. The suppression is scoped
+entirely to the registration calls; all other Pydantic warnings remain unaffected.
+
+### Improvements
+
+#### Column rename detection in migration SQL
+
+Alter's diff engine is name-based and cannot distinguish a column rename from a
+drop + add of the same type. When `_migration_sql()` detects this pattern — a
+`drop_column` and an `add_column` on the same table whose dropped column and added
+column share the same type — the generated SQL now includes a warning comment:
+
+```sql
+-- WARNING: 'orders.note' is being dropped while 'notes' (same type) is being added.
+-- If this is a rename, replace the ADD+DROP below with:
+--   ALTER TABLE orders RENAME COLUMN note TO notes;
+```
+
+This makes it easy to spot a likely rename and swap the destructive ADD+DROP for a
+safe `RENAME COLUMN` before executing the migration.
+
+#### Improved initial canvas layout
+
+The ELK graph layout used for the first-open auto-arrange now produces cleaner ERD
+diagrams. Changes:
+
+- Direction changed from `RIGHT` to `DOWN` — tables flow top-to-bottom, which reads
+  more naturally as an entity-relationship diagram.
+- Node spacing increased from 60 px to 120 px, edge-to-node layer spacing from 80 px
+  to 130 px — tables no longer overlap on medium-sized schemas.
+- `BRANDES_KOEPF` node placement and `GREEDY` cycle-breaking strategies added for
+  more compact, symmetrical layouts.
+- Grid fallback spacing increased (`290 → 400 px` column width, `310 → 420 px` row
+  height) for schemas that fall back to the simpler grid arrangement.
+
+## [0.2.3] — 2026-03-15
+
+### Bug Fixes
+
+#### `alter mcp` crashes with a cryptic `ModuleNotFoundError` when `mcp < 1.2.0` (Bug A)
+
+`alter mcp` calls `init_mcp()` which imports `FastMCP` from `mcp.server.fastmcp`. That
+submodule was introduced in `mcp 1.2.0`; older installations raise a bare
+`ModuleNotFoundError: No module named 'mcp.server.fastmcp'` with no indication of how
+to fix it.
+
+`init_mcp()` now wraps the import in a `try/except ImportError` and raises an
+`AlterError` with an actionable message:
+
+```
+'alter mcp' requires mcp>=1.2.0, but mcp==1.1.3 is installed.
+Upgrade with: pip install 'mcp>=1.2.0'
+```
+
+The error surfaces cleanly in the CLI (no "MCP server error:" prefix) because the CLI
+already handles `AlterError` separately from generic exceptions.
+
+A second guard wraps the cosmetic `_mcp_server.version` assignment in
+`try/except AttributeError` so that future changes to `mcp` internals do not break
+`alter mcp` startup.
+
+#### `alter apply` spuriously rewrites `datetime.now(timezone.utc)` defaults on Python 3.11+ (Bug B)
+
+When a model file contained a column with `default_factory=lambda: datetime.now(timezone.utc)`,
+running `alter apply` on Python 3.11+ would rewrite the line even though nothing had
+changed in the schema.
+
+Root cause: `_parse_field_kwargs` normalises kwargs via `ast.unparse`, and the Python
+`ast` module changed how it serialises zero-argument lambdas between versions —
+Python ≤ 3.10 produces `"lambda :"` (with a space after `lambda`), while Python 3.11+
+produces `"lambda:"` (no space). Because `ast.unparse` is applied to both the
+existing code and the freshly generated schema line, the comparison reached different
+sides of the `_DEFAULT_FACTORY_EQUIV` lookup depending on the Python version in use,
+causing the surgical patcher to believe a change was needed when there was none.
+
+Two-part fix in `generators/_surgical.py`:
+
+1. **`_norm_lambda_ws()` helper** — strips extraneous whitespace between `lambda` and
+   `:` for zero-argument lambdas (`re.sub(r"^lambda\s*:", "lambda:", s)`), making
+   lambda strings compare equal across Python versions.
+
+2. **Normalization applied consistently** — `_normalize_kw_for_eq` now calls
+   `_norm_lambda_ws` on `default_factory` values after the `_DEFAULT_FACTORY_EQUIV`
+   lookup, so both the existing-file side and the schema side are normalised before
+   comparison. The rebuild path in `_rebuild_field_line` applies the same
+   normalization when checking whether the existing value is canonically equivalent.
+
+The `_DEFAULT_FACTORY_EQUIV` dict value for `utcnow` was also corrected from
+`"lambda : datetime.now(timezone.utc)"` (with spurious space, matching old Python 3.10
+`ast.unparse` output) to `"lambda: datetime.now(timezone.utc)"` (canonical form) — the
+`_norm_lambda_ws` normalization then makes both forms match on all Python versions.
+
+---
+
 ## [0.2.2] — 2026-03-15
 
 ### Bug Fixes

{alterdb-0.2.2 → alterdb-0.2.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: alterdb
-Version: 0.2.2
+Version: 0.2.4
 Summary: Visual schema design for SQLModel and SQLAlchemy. Edit your database as a diagram, write it back as code.
 Project-URL: Homepage, https://github.com/chimi-labs/alter
 Project-URL: Repository, https://github.com/chimi-labs/alter
@@ -28,6 +28,10 @@ Provides-Extra: db
 Requires-Dist: psycopg2-binary>=2.9; extra == 'db'
 Description-Content-Type: text/markdown
 
+<p align="center">
+  <img src="https://raw.githubusercontent.com/chimi-labs/alter/main/docs/alter_logo.png" alt="Alter" width="320" />
+</p>
+
 # Alter
 
 > Comprehension first, design second.
@@ -79,7 +83,7 @@ uv add alterdb
 > This keeps Alter's dependencies completely separate from your project's virtual environment while
 > making the `alter` command available on your `PATH`.
 
-> **Live database introspection** (MCP `introspect_db` tool): requires `psycopg2-binary`, install with `pip install alterdb[db]`.
+> **Live database features** (MCP `introspect_db`, `query_db`, `describe_table_data`, `explain_query` tools): requires `psycopg2-binary`, install with `pip install alterdb[db]`.
 
 ## Quick Start
 
@@ -160,6 +164,10 @@ alter apply --preview   # see exactly what will change (unified diff)
 alter apply             # write the changes to your model files
 ```
 
+> **Apply to Code auto-commits:** clicking **Apply to Code** in the canvas automatically commits
+> any pending staged changes to `schema.alter` before writing to your model files — so you never
+> accidentally apply a stale snapshot.
+
 `alter apply` is surgical — it only touches what the schema says has changed:
 
 - **Additions** — new tables are appended as new classes; new columns are inserted after the last existing field.
@@ -244,6 +252,12 @@ Alter generates the SQL — you run it with whatever migration tool you already
 The **Migrations tab** in the canvas shows the pending SQL at any time. The `preview_migration`
 MCP tool returns the same SQL to AI assistants. Copy it into your migration manager of choice.
 
+> **Column rename detection:** Alter's diff engine is name-based and cannot distinguish a column
+> rename from a drop + add. When it detects a `DROP COLUMN` paired with an `ADD COLUMN` of the
+> same type on the same table, the generated SQL includes a comment pointing out the potential
+> rename and showing the equivalent `ALTER TABLE … RENAME COLUMN` statement. Review this comment
+> before running the migration to avoid accidental data loss.
+
 ### With Alembic (one-time setup)
 
 ```bash
@@ -519,7 +533,17 @@ alter init    # scan your ORM models → create schema.alter
 
 The MCP server requires `schema.alter` to exist before it can start.
 
-**Step 2 — Register the server in your editor.**
+**Step 2 — Ensure `mcp>=1.2.0` is installed.**
+
+`alter mcp` requires `mcp>=1.2.0` (the `FastMCP` API used internally was added in that release). If you see an error on startup, upgrade:
+
+```bash
+pip install 'mcp>=1.2.0'
+# or
+uv add 'mcp>=1.2.0'
+```
+
+**Step 3 — Register the server in your editor.**
 
 Most editors use the same JSON config. Add this to your MCP settings file:
 
@@ -551,7 +575,7 @@ claude mcp add alter -- uv run --directory /path/to/project alter mcp
 > **Why `uv run`?** It ensures the command runs inside your project's virtual environment,
 > picking up the correct `alterdb` version and dependencies — no manual `source .venv/bin/activate` needed.
 
-**Step 3 — Restart your editor** (or open a new session) so the MCP server connects. Verify by asking:
+**Step 4 — Restart your editor** (or open a new session) so the MCP server connects. Verify by asking:
 
 > _"What tools do you have available from alter?"_
 
@@ -564,8 +588,14 @@ claude mcp add alter -- uv run --directory /path/to/project alter mcp
 - **Preview migration SQL** — see the DDL that needs to run for pending changes
 - **Undo/redo** any staged change
 - **Commit** approved changes to `schema.alter`
+- **Apply to code** — write committed schema changes to your ORM model files
 - **Export** as SQL, Mermaid, or JSON
 - **Validate** the schema for errors
+- **Query live data** — run read-only SQL against a real database and get results back (see below)
+
+> **`apply_to_code` requires a prior commit:** if there are uncommitted staged changes when
+> `apply_to_code()` is called, the tool returns a message asking you to call `commit_changes()`
+> first. This prevents silently applying a stale snapshot while discarding your pending edits.
 
 ### Example prompts
 
@@ -597,6 +627,131 @@ Once connected, just talk to your assistant:
 The assistant stages changes, shows you a diff, and only commits to `schema.alter` with your
 approval — nothing is written to your model files until you also run `alter apply`.
 
+### Querying live data
+
+Alter's MCP server can also run read-only SQL queries against a live PostgreSQL database,
+so your AI assistant can answer questions about actual data — not just schema structure.
+
+**Setup**
+
+**1 — Install the database extra** (if you haven't already):
+
+```bash
+pip install alterdb[db]
+# or
+uv add alterdb[db]
+```
+
+This adds `psycopg2-binary`, which is required for all live database tools.
+
+**2 — Set the `DATABASE_URL` environment variable** before starting your editor or MCP session:
+
+```bash
+export DATABASE_URL="postgresql://user:password@localhost:5432/mydb"
+```
+
+Or add it to your editor's MCP config so it's always available:
+
+```json
+{
+  "mcpServers": {
+    "alter": {
+      "command": "uv",
+      "args": ["run", "--directory", "/path/to/project", "alter", "mcp"],
+      "env": {
+        "DATABASE_URL": "postgresql://user:password@localhost:5432/mydb"
+      }
+    }
+  }
+}
+```
+
+That's it. No other configuration needed — the tools pick up `DATABASE_URL` automatically.
+
+**The three data tools**
+
+| Tool | What it does |
+|------|-------------|
+| `query_db` | Execute a SELECT query, return results as a table, JSON, or CSV |
+| `describe_table_data` | Show row count, column types, relationships, and sample rows for a table |
+| `explain_query` | Show PostgreSQL's query execution plan (without running the query) |
+
+All queries run in a **read-only transaction** — INSERT, UPDATE, DELETE, and DDL are
+blocked at the database level. Results are capped at 1,000 rows (default: 100).
+
+**Example prompts**
+
+_"How many users signed up in the last 30 days?"_
+
+The assistant calls `read_schema` to see the `users` table has a `created_at` column,
+then calls `query_db`:
+```
+| count |
+| 847   |
+
+1 row in 4ms
+```
+→ _"847 users signed up in the last 30 days."_
+
+---
+
+_"Which plan do most of our paying customers use?"_
+
+```
+| plan    | count |
+| pro     | 1,204 |
+| starter | 891   |
+| team    | 342   |
+
+3 rows in 12ms
+```
+
+---
+
+_"Tell me about the orders table before I write a query against it"_
+
+The assistant calls `describe_table_data("orders")`:
+```
+Table: public.orders (24,871 rows)
+
+Columns:
+  id:          uuid        NOT NULL DEFAULT gen_random_uuid()
+  user_id:     uuid        NOT NULL
+  status:      varchar     NOT NULL
+  total_cents: integer     NOT NULL
+  created_at:  timestamptz NOT NULL DEFAULT now()
+
+References (outgoing):
+  orders.user_id → users.id (CASCADE)
+
+Referenced by (incoming):
+  order_items.order_id → orders.id (CASCADE)
+
+Sample data (5 rows):
+id     | user_id | status    | total_cents | created_at
+-------+---------+-----------+-------------+-----------
+a1b2…  | x9y0…   | completed | 4999        | 2024-03-01…
+…
+```
+
+---
+
+_"Why is my query slow? EXPLAIN this: SELECT * FROM orders JOIN users ON orders.user_id = users.id WHERE orders.status = 'pending'"_
+
+The assistant calls `explain_query` and returns the plan — no rows are fetched, no data
+is affected.
+
+```
+Hash Join  (cost=18.50..1842.30 rows=312 width=156)
+  Hash Cond: (orders.user_id = users.id)
+  ->  Seq Scan on orders  (cost=0.00..1810.71 rows=312 ...)
+        Filter: ((status)::text = 'pending'::text)
+  ->  Hash  (cost=14.70..14.70 rows=304 ...)
+        ->  Seq Scan on users  (cost=0.00..14.70 rows=304 ...)
+```
+
+→ _"The sequential scan on `orders` is the bottleneck — adding an index on `orders.status` would speed this up significantly."_
+
 ## Supported ORMs
 
 - **SQLModel** — auto-detected from `from sqlmodel import ...`

{alterdb-0.2.2 → alterdb-0.2.4}/README.md

@@ -1,3 +1,7 @@
+<p align="center">
+  <img src="https://raw.githubusercontent.com/chimi-labs/alter/main/docs/alter_logo.png" alt="Alter" width="320" />
+</p>
+
 # Alter
 
 > Comprehension first, design second.
@@ -49,7 +53,7 @@ uv add alterdb
 > This keeps Alter's dependencies completely separate from your project's virtual environment while
 > making the `alter` command available on your `PATH`.
 
-> **Live database introspection** (MCP `introspect_db` tool): requires `psycopg2-binary`, install with `pip install alterdb[db]`.
+> **Live database features** (MCP `introspect_db`, `query_db`, `describe_table_data`, `explain_query` tools): requires `psycopg2-binary`, install with `pip install alterdb[db]`.
 
 ## Quick Start
 
@@ -130,6 +134,10 @@ alter apply --preview   # see exactly what will change (unified diff)
 alter apply             # write the changes to your model files
 ```
 
+> **Apply to Code auto-commits:** clicking **Apply to Code** in the canvas automatically commits
+> any pending staged changes to `schema.alter` before writing to your model files — so you never
+> accidentally apply a stale snapshot.
+
 `alter apply` is surgical — it only touches what the schema says has changed:
 
 - **Additions** — new tables are appended as new classes; new columns are inserted after the last existing field.
@@ -214,6 +222,12 @@ Alter generates the SQL — you run it with whatever migration tool you already
 The **Migrations tab** in the canvas shows the pending SQL at any time. The `preview_migration`
 MCP tool returns the same SQL to AI assistants. Copy it into your migration manager of choice.
 
+> **Column rename detection:** Alter's diff engine is name-based and cannot distinguish a column
+> rename from a drop + add. When it detects a `DROP COLUMN` paired with an `ADD COLUMN` of the
+> same type on the same table, the generated SQL includes a comment pointing out the potential
+> rename and showing the equivalent `ALTER TABLE … RENAME COLUMN` statement. Review this comment
+> before running the migration to avoid accidental data loss.
+
 ### With Alembic (one-time setup)
 
 ```bash
@@ -489,7 +503,17 @@ alter init    # scan your ORM models → create schema.alter
 
 The MCP server requires `schema.alter` to exist before it can start.
 
-**Step 2 — Register the server in your editor.**
+**Step 2 — Ensure `mcp>=1.2.0` is installed.**
+
+`alter mcp` requires `mcp>=1.2.0` (the `FastMCP` API used internally was added in that release). If you see an error on startup, upgrade:
+
+```bash
+pip install 'mcp>=1.2.0'
+# or
+uv add 'mcp>=1.2.0'
+```
+
+**Step 3 — Register the server in your editor.**
 
 Most editors use the same JSON config. Add this to your MCP settings file:
 
@@ -521,7 +545,7 @@ claude mcp add alter -- uv run --directory /path/to/project alter mcp
 > **Why `uv run`?** It ensures the command runs inside your project's virtual environment,
 > picking up the correct `alterdb` version and dependencies — no manual `source .venv/bin/activate` needed.
 
-**Step 3 — Restart your editor** (or open a new session) so the MCP server connects. Verify by asking:
+**Step 4 — Restart your editor** (or open a new session) so the MCP server connects. Verify by asking:
 
 > _"What tools do you have available from alter?"_
 
@@ -534,8 +558,14 @@ claude mcp add alter -- uv run --directory /path/to/project alter mcp
 - **Preview migration SQL** — see the DDL that needs to run for pending changes
 - **Undo/redo** any staged change
 - **Commit** approved changes to `schema.alter`
+- **Apply to code** — write committed schema changes to your ORM model files
 - **Export** as SQL, Mermaid, or JSON
 - **Validate** the schema for errors
+- **Query live data** — run read-only SQL against a real database and get results back (see below)
+
+> **`apply_to_code` requires a prior commit:** if there are uncommitted staged changes when
+> `apply_to_code()` is called, the tool returns a message asking you to call `commit_changes()`
+> first. This prevents silently applying a stale snapshot while discarding your pending edits.
 
 ### Example prompts
 
@@ -567,6 +597,131 @@ Once connected, just talk to your assistant:
 The assistant stages changes, shows you a diff, and only commits to `schema.alter` with your
 approval — nothing is written to your model files until you also run `alter apply`.
 
+### Querying live data
+
+Alter's MCP server can also run read-only SQL queries against a live PostgreSQL database,
+so your AI assistant can answer questions about actual data — not just schema structure.
+
+**Setup**
+
+**1 — Install the database extra** (if you haven't already):
+
+```bash
+pip install alterdb[db]
+# or
+uv add alterdb[db]
+```
+
+This adds `psycopg2-binary`, which is required for all live database tools.
+
+**2 — Set the `DATABASE_URL` environment variable** before starting your editor or MCP session:
+
+```bash
+export DATABASE_URL="postgresql://user:password@localhost:5432/mydb"
+```
+
+Or add it to your editor's MCP config so it's always available:
+
+```json
+{
+  "mcpServers": {
+    "alter": {
+      "command": "uv",
+      "args": ["run", "--directory", "/path/to/project", "alter", "mcp"],
+      "env": {
+        "DATABASE_URL": "postgresql://user:password@localhost:5432/mydb"
+      }
+    }
+  }
+}
+```
+
+That's it. No other configuration needed — the tools pick up `DATABASE_URL` automatically.
+
+**The three data tools**
+
+| Tool | What it does |
+|------|-------------|
+| `query_db` | Execute a SELECT query, return results as a table, JSON, or CSV |
+| `describe_table_data` | Show row count, column types, relationships, and sample rows for a table |
+| `explain_query` | Show PostgreSQL's query execution plan (without running the query) |
+
+All queries run in a **read-only transaction** — INSERT, UPDATE, DELETE, and DDL are
+blocked at the database level. Results are capped at 1,000 rows (default: 100).
+
+**Example prompts**
+
+_"How many users signed up in the last 30 days?"_
+
+The assistant calls `read_schema` to see the `users` table has a `created_at` column,
+then calls `query_db`:
+```
+| count |
+| 847   |
+
+1 row in 4ms
+```
+→ _"847 users signed up in the last 30 days."_
+
+---
+
+_"Which plan do most of our paying customers use?"_
+
+```
+| plan    | count |
+| pro     | 1,204 |
+| starter | 891   |
+| team    | 342   |
+
+3 rows in 12ms
+```
+
+---
+
+_"Tell me about the orders table before I write a query against it"_
+
+The assistant calls `describe_table_data("orders")`:
+```
+Table: public.orders (24,871 rows)
+
+Columns:
+  id:          uuid        NOT NULL DEFAULT gen_random_uuid()
+  user_id:     uuid        NOT NULL
+  status:      varchar     NOT NULL
+  total_cents: integer     NOT NULL
+  created_at:  timestamptz NOT NULL DEFAULT now()
+
+References (outgoing):
+  orders.user_id → users.id (CASCADE)
+
+Referenced by (incoming):
+  order_items.order_id → orders.id (CASCADE)
+
+Sample data (5 rows):
+id     | user_id | status    | total_cents | created_at
+-------+---------+-----------+-------------+-----------
+a1b2…  | x9y0…   | completed | 4999        | 2024-03-01…
+…
+```
+
+---
+
+_"Why is my query slow? EXPLAIN this: SELECT * FROM orders JOIN users ON orders.user_id = users.id WHERE orders.status = 'pending'"_
+
+The assistant calls `explain_query` and returns the plan — no rows are fetched, no data
+is affected.
+
+```
+Hash Join  (cost=18.50..1842.30 rows=312 width=156)
+  Hash Cond: (orders.user_id = users.id)
+  ->  Seq Scan on orders  (cost=0.00..1810.71 rows=312 ...)
+        Filter: ((status)::text = 'pending'::text)
+  ->  Hash  (cost=14.70..14.70 rows=304 ...)
+        ->  Seq Scan on users  (cost=0.00..14.70 rows=304 ...)
+```
+
+→ _"The sequential scan on `orders` is the bottleneck — adding an index on `orders.status` would speed this up significantly."_
+
 ## Supported ORMs
 
 - **SQLModel** — auto-detected from `from sqlmodel import ...`

{alterdb-0.2.2 → alterdb-0.2.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "alterdb"
-version = "0.2.2"
+version = "0.2.4"
 description = "Visual schema design for SQLModel and SQLAlchemy. Edit your database as a diagram, write it back as code."
 license = "MIT"
 license-files = ["LICENSE"]