Query Dashboard Data

Execute SQL across all project databases + side tables.

DuckDB over each table's OWN storage — a Database's Parquet, never an entity read. A dashboard queries DATABASES: pipeline outputs, addressed by display_name, and pipelines write databases, not entities (of Colisée's 1801 databases, 12 are promoted). query_tables registers each referenced table independently as a read_parquet view and joins them in one DuckDB session; per-table independence is the property that matters, because one un-promoted table among ten must not decide how the other nine are read.

Two paths were tried here and both are gone. Routing the whole query through entity_reads.oltp resolved every identifier against bindings, which only an entity-backed table can appear in — so a single reference to an un-promoted table became UnknownEntity -> 400 for the entire query, i.e. for the overwhelming majority of what a dashboard reads (reverted in #791). And query_tables itself used to carry an entity branch that served a promoted table from its DuckLake table; that went with DuckLake, and it is deliberately NOT replaced by the Parquet mirror. Entities and databases are different storage, and this surface reads database storage.

The consequence, stated rather than discovered: a dashboard over a promoted table reads the SOURCE image, so it does not reflect user edits, tombstones or managed columns — and a managed column exists ONLY in Postgres, so SQL naming one fails with a missing-column error rather than returning stale values. A dashboard that needs an entity's edited view is asking for an entity read, which is what /api/v1/ontology/entities/{id}/query and the apps query endpoint are for.