You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The example focuses on catalog routing. When separate workflows operate on the projects, configure
207
+
them to use the same state backend or scheduler so they read and update the same SQLMesh
208
+
environment. See the [multi-repository guide](multi_repo.md) for the shared-state configuration.
209
+
210
+
For a model named `sales.orders` using the `project_a` gateway, this configuration stores
211
+
versioned snapshot tables under `project_a_physical` and creates the environment's `sales.orders`
212
+
view under `project_a_published`. SQLMesh resolves and stores this route with the snapshot, so a
213
+
later plan that loads only one project retains the routes of models loaded from shared state.
214
+
215
+
The gateway route is the base catalog for normal environment naming. Existing naming settings
216
+
retain their precedence:
217
+
218
+
- A matching `environment_catalog_mapping` target overrides `virtual_layer_catalog`.
219
+
- With `environment_suffix_target: catalog`, a development environment suffix is appended to
220
+
`virtual_layer_catalog`.
221
+
- If neither setting changes the catalog, `virtual_layer_catalog` is used as configured.
222
+
223
+
Changing only `virtual_layer_catalog` is a metadata-only model change. Applying the plan creates
224
+
the view at its new location and removes the view at its previous location without rebuilding the
225
+
physical snapshot table. Ensure the gateway can create and drop objects in both catalogs during a
226
+
route change. All composed project configurations that define the same gateway name must agree on
227
+
its `virtual_layer_catalog`; SQLMesh rejects conflicting routes.
228
+
229
+
`virtual_layer_catalog` is gateway-level configuration. It cannot be set in a `MODEL` block or in
230
+
`model_defaults`. External models are source definitions and do not inherit this publishing route.
231
+
137
232
#### Example: Redshift + Athena + Snowflake
138
233
139
234
Consider a scenario where you need to create a project with models in Redshift, Athena and Snowflake, where each engine hosts its models' virtual layer views.
Copy file name to clipboardExpand all lines: docs/reference/configuration.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -186,6 +186,7 @@ NOTE: Spark and Trino engines may not be used for the state connection.
186
186
| `connection` | The data warehouse connection for core SQLMesh functions. | [connection configuration](#connection) | N (if [`default_connection`](#default-connectionsscheduler) specified) |
187
187
| `state_connection` | The data warehouse connection where SQLMesh will store internal information about the project. (Default: `connection`if using builtin scheduler, otherwise scheduler database) | [connection configuration](#connection) | N |
188
188
| `state_schema` | The name of the schema where state information should be stored. (Default: `sqlmesh`) | string | N |
189
+
| `virtual_layer_catalog` | The catalog where this gateway publishes virtual-layer views. This does not change the catalog used for physical snapshot tables. Intended for use with [`gateway_managed_virtual_layer`](../guides/multi_engine.md#gateway-managed-virtual-layer). | string | N |
189
190
| `test_connection` | The data warehouse connection SQLMesh will use to execute tests. (Default: `connection`) | [connection configuration](#connection) | N |
190
191
| `scheduler` | The scheduler SQLMesh will use to execute tests. (Default: `builtin`) | [scheduler configuration](#scheduler) | N |
191
192
| `variables` | The gateway-specific variables which override the root-level [variables](#variables) by key. | dict[string, int \| float \| bool \| string \| list \| dict] | N |
0 commit comments