Fix SQLite generated table column metadata

[DhruvShah-Dev]

Summary

• use SQLite table_xinfo for table column metadata so generated columns are included in table grids
• expose generated-column metadata and keep generated columns out of insert/update paths
• update the regression coverage for table metadata, batch table metadata, and generated-column write rejection

Testing

• pnpm.cmd exec vitest run tests/utils/pendingInsertions.test.ts --pool=threads --maxWorkers=1
• pnpm.cmd typecheck
• pnpm.cmd lint
• cargo test --manifest-path src-tauri/Cargo.toml drivers::sqlite::tests::test_generated_table_columns_are_not_inserted_or_updated --lib --no-run --jobs 1

Note: the targeted Rust test compiles locally, but direct execution on this Windows environment exits before the harness runs with STATUS_ENTRYPOINT_NOT_FOUND.

Fixes #162

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Files Reviewed (1 file)

• src-tauri/src/drivers/sqlite/tests.rs

Previous Review Summaries (2 snapshots, latest commit 6087646)

Current summary above is authoritative. Previous snapshots are kept for context only.

Previous review (commit 6087646)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• src-tauri/src/drivers/sqlite/mod.rs
• src-tauri/src/drivers/sqlite/tests.rs

Previous review (commit 4764730)

Status: No Issues Found | Recommendation: Merge

Files Reviewed (2 files)

• src-tauri/src/drivers/sqlite/mod.rs
• src-tauri/src/drivers/sqlite/tests.rs

---

_{Reviewed by step-3.7-flash · Input: 297.4K · Output: 43K · Cached: 7.1M}

[debba]

Thanks for looking into this, but I don't think this actually fixes #162.

The repro in the issue is a plain table with a generated column, no view involved. I tested against a real database (system SQLite 3.51 and the bundled 3.46 behave the same):

• PRAGMA table_info on the table only returns udate, the generated column is missing. table_xinfo returns it (hidden=3 for STORED, hidden=2 for VIRTUAL). That mismatch between column metadata and the SELECT * data is exactly the grid misalignment in the issue's screenshot.
• On a view over that table, table_info already returns all the columns, same output as table_xinfo. Columns coming from generated columns are just ordinary view columns.

So the change in get_view_columns is a no-op for this bug. The functions the grid actually uses for tables, get_columns (src-tauri/src/drivers/sqlite/mod.rs:67) and get_all_columns_batch (mod.rs:160), still use table_info and are still broken.

The new test also passes without the fix: I reverted line 841 back to table_info, rebuilt, and test_get_view_columns_includes_generated_table_columns still passes. Note that the test command in the description uses --no-run, so it compiles the test but never runs it, which is probably how this slipped through.

For a proper fix I'd suggest:

1. Switch get_columns and get_all_columns_batch to table_xinfo. Keeping the view change is fine, it's harmless.
2. Be careful with writes: generated columns can't be inserted or updated, and TableColumn has no is_generated flag, so exposing them in table metadata may let the row editor build INSERT/UPDATE statements that SQLite rejects. The hidden value from table_xinfo (2 = virtual, 3 = stored) is what you need to flag them.
3. The regression test should target get_columns on the table itself, and should be verified to fail on main before the fix.

Happy to re-review once it's updated.

[DhruvShah-Dev]

Updated this based on the review.

Changes made:

• switched table metadata paths (get_columns and get_all_columns_batch) from table_info to table_xinfo
• added generated-column metadata from SQLite hidden values 2 and 3
• kept generated columns out of insert/update paths so they can be displayed without being written to
• replaced the view-focused regression with table metadata coverage, including the batch path

Validation:

• pnpm.cmd exec vitest run tests/utils/pendingInsertions.test.ts --pool=forks --maxWorkers=1
• pnpm.cmd typecheck
• pnpm.cmd lint
• pnpm.cmd build
• cargo test --manifest-path src-tauri/Cargo.toml drivers::sqlite::tests::test_get_columns_includes_generated_table_columns --lib --no-run

The Rust test compiles locally. Direct execution on my Windows environment exits before the harness runs with STATUS_ENTRYPOINT_NOT_FOUND, so I documented the compile-only Rust validation in the PR body.

[DhruvShah-Dev]

Updated this with additional backend regression coverage for the write-path concern from the review.

Changes made:

• added a SQLite regression test that rejects inserts containing generated columns
• added a SQLite regression test that rejects updates targeting generated columns
• kept the existing table metadata and batch metadata coverage in place

Validation:

• pnpm.cmd exec vitest run tests/utils/pendingInsertions.test.ts --pool=threads --maxWorkers=1
• pnpm.cmd typecheck
• pnpm.cmd lint
• cargo test --manifest-path src-tauri/Cargo.toml drivers::sqlite::tests::test_generated_table_columns_are_not_inserted_or_updated --lib --no-run --jobs 1

Direct Rust test execution still exits before the harness starts on my Windows environment with STATUS_ENTRYPOINT_NOT_FOUND, so I validated that the targeted Rust test compiles successfully.

[debba]

Thanks a lot for this one! I reviewed it locally and tested against a db with both STORED and VIRTUAL generated columns: metadata comes through correctly, the grid finally shows the computed values and the write paths reject them as expected. The two new Rust tests also pass fine here on Linux, so the STATUS_ENTRYPOINT_NOT_FOUND thing was just your local Windows setup.

One small follow-up we can handle separately: table_xinfo also returns hidden columns of virtual tables (hidden=1, e.g. the docs/rank columns of fts5 tables), which now show up in the new row modal as editable fields. Filtering those rows out would restore the old behavior there.

Great work, merging now.

[debba]

All the points from my previous review are addressed now, and I verified the new tests actually run and pass this time. Approving.