Skip to main content

Module introspect

Module introspect 

Source
Expand description

Schema introspection - sqlx::Any has no portable “list tables”/ “describe table” API of its own (confirmed by reading its source: the only “meta” operations it exposes are database-level create/drop, for sqlx::migrate, nothing table/column-level). Every function here hand-writes the per-backend catalog query - sqlite_master/PRAGMA table_info for SQLite, the standard SQL-92 information_schema views for MySQL/Postgres - and decodes the result through the exact same generic row-reading path (sqlx::Row) everything else in this crate’s sql module uses.

Structs§

ColumnInfo
One column’s shape - enough to render an edit input and bind a submitted value back to it correctly (see codec::json_to_any_value). A Blob-kind column is a known, stated v1 gap, not silently mishandled: the browse view renders its value as <blob, N bytes> (never the raw bytes), and a submitted value for one is stored as plain text rather than real binary - dashboard::sql_views’s edit/insert forms don’t yet special-case it with a distinct (disabled, or upload-shaped) input, so editing one through the dashboard silently overwrites it with UTF-8 text. No table in demo or the framework’s own schema has one today.

Functions§

list_foreign_keys
table’s foreign keys, one row per referencing column. Same shape/ rendering rationale as list_indexes.
list_indexes
table’s indexes, one row per index (shape varies by backend - see each arm below). Rendered through the same generic result-table machinery as the raw /sql page’s output (codec::row_to_json handles any AnyRow, PRAGMA/SHOW output included), not a bespoke parsed struct - this is a read-only viewer, the raw columns are the point. Same “caller already validated table” contract as table_columns.
list_tables
Every real table in the connected database, alphabetical - delegates to larust_orm::table_names(), which hand-writes this same per-backend catalog query for its own [larust_orm::migrate::fresh]; kept as one query with two callers rather than duplicated here.
primary_key_columns
table’s primary key column(s), in key order - composite-safe. Same “caller already validated table” contract as table_columns.
table_columns
table’s columns, in declaration order. Callers MUST have already validated table against list_tables - SQLite’s PRAGMA can’t take a bind parameter for the table name, so it’s interpolated directly, safe only because it’s guaranteed to be a real, existing table name by the time this runs, never raw user input.