kater workspace source use

Sets the shared model that a workspace reads, or changes it to another one.

Only the model that the workspace’s SQL reads from changes, and the rest of the SQL stays. Run it with --dry-run first to see the new workspace.sql.

Examples

# Go to the snowflake_prod_connection connection in your local copy of Kater content
cd connections/snowflake_prod_connection
# Make the ad_reporting workspace read the shared ad_reporting model
kater workspace source use semantic.ad_reporting --scope workspaces/ad_reporting
# See what changes when it reads the campaign report model, and save nothing
kater workspace source use semantic.ad_reporting__campaign_report --scope workspaces/ad_reporting --dry-run
# See the workspace's SQL as a query of every field of the model, and save nothing
kater workspace source use semantic.ad_reporting --scope workspaces/ad_reporting --reset --dry-run
# Check which queries and filters a change of model touches, with the request in check.json
kater workspace source use --request-file check.json

Arguments

Argument	Description
`<model>`	Optional. The shared model for the workspace to read: a semantic model or a Kater dataset, by its name or its address, such as `semantic.ad_reporting`. Leave it out only with `--request-file`.

Options

Option	Description
`--request-file <file>`	A JSON file that holds a whole request, such as a check that writes nothing. `-` reads it from standard input. With it, the command does not read `MODEL`, `--reset` or `--dry-run`. See Check a change before you make it.
`--reset`	Replaces the workspace’s SQL with a query of every field of the model. Without it, only the model that the SQL reads changes.
`--dry-run`	Shows the change to `workspace.sql`, and saves nothing.

It also takes the global options --json, --kater-root, --scope and --help.

Which workspace changes

Name the workspace with --scope, by its folder. Without --scope, Kater uses the scope that kater scope use saved, or else the folder you are in.

What changes

The workspace’s SQL keeps its filters and the fields it adds. Only the model it reads from changes. A filter or an added field can read a field that the new model does not have. The new workspace.sql then leaves that filter or field out.

Check a change before you make it

A request with "action": "check" says what changes when the workspace reads another model, and writes nothing. It names each query that compiles against the workspace, each filter, and each field the workspace adds. Without from_model, it checks the model that the workspace reads now. It names the queries that read a field the model does not have.

{"action": "check", "namespace": {"path": "connections/snowflake_prod_connection/workspaces/ad_reporting"}, "from_model": "semantic.ad_reporting__campaign_report"}

The request takes other actions too. options lists the models the workspace can read. prepare proposes the new workspace.sql, and apply writes it with the revision that prepare gave.