Skip to main content
Use warehouse_query to explore raw and modeled data before writing or updating SQL models. You can query production data or route to a workspace’s private clone.

​
Parameters

​
string
required
The DuckDB SQL query to execute. Supports all standard DuckDB syntax including analytical functions, SUMMARIZE, DESCRIBE, SHOW, and EXPLAIN.
​
string
Routes the query to a specific workspace’s data clone, where that workspace’s bronze and silver views live. Omit to query the production warehouse.
​
integer
default:"100"
Maximum number of rows returned. Capped at 1000. Soria automatically appends LIMIT {limit} to your query unless it is a SUMMARIZE, DESCRIBE, SHOW, or EXPLAIN statement.

​
Automatic LIMIT injection

Soria injects LIMIT {limit} at the end of any SELECT query that does not already include a LIMIT clause. The following statement types are exempt — they run as written, without any limit appended:

​
Workspace routing

When you pass workspace_id, Soria routes the query to that workspace’s data clone instead of production. This is where bronze source tables and silver staging views created in that workspace are materialized. Use this when you want to validate model output in an isolated environment before promoting.
Omit workspace_id entirely to query the production warehouse. There is no default workspace — omitting the parameter always targets prod.

​
Example queries

​
Profile a table’s structure and statistics

Returns min, max, approximate distinct count, null count, and mean for every column — no LIMIT is applied.

​
Explore distinct categorical values

​
Inspect type distribution

Useful for catching mixed-type columns before writing CAST expressions in a silver model.

​
Preview raw rows

Because this query already includes LIMIT, Soria does not append a second one.

​
Query a workspace clone

To run the same preview against a workspace instead of production, pass workspace_id:

​
warehouse_materialize

Use warehouse_materialize to rebuild a SQL model’s physical representation in the warehouse — switching it between a TABLE (materialized snapshot, faster reads) and a VIEW (always-current, chains to upstream).

​
Parameters

​
string
required
Fully qualified model name, e.g. silver.stg_az_medicaid_enrollment. Must match the name field in the model’s MODEL block.
​
boolean
default:"true"
true creates a physical TABLE. false reverts to a VIEW.
​
string
default:"prod"
Target workspace identifier, e.g. ws_pa_medicaid_8a3f1b92. Defaults to prod for the production warehouse.

​
When to use it

  • After promoting a gold or platinum model you want to serve dashboard queries faster, set materialize=true.
  • If the underlying source data changes frequently and you want the view to always reflect the latest rows, revert with materialize=false.
  • After a schema change breaks a view, materialize can be used to force a clean rebuild from the current SQL.

​
Example — materialize a silver model in a workspace

​
Example — revert a gold model to a view in production

If the warehouse reports an “Existing object” conflict, the previous object type (TABLE vs. VIEW) needs to be manually dropped before warehouse_materialize can proceed. Check server logs for the specific error message.