Skip to content

Commit bd2caa9

Browse files
treyspsungchun12
treysp
and
sungchun12
authored
Feat: interactive sqlmesh init (#4726)
Co-authored-by: Sung Won Chung <[email protected]>
1 parent 28127d4 commit bd2caa9

File tree

23 files changed

+1137
-517
lines changed

23 files changed

+1137
-517
lines changed

‎docs/guides/configuration.md‎

Lines changed: 73 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -151,6 +151,55 @@ The examples specify a Snowflake connection whose password is stored in an envir
151151
)
152152
```
153153

154+
#### Default target environment
155+
156+
The SQLMesh `plan` command acts on the `prod` environment by default (i.e., `sqlmesh plan` is equivalent to `sqlmesh plan prod`).
157+
158+
In some organizations, users never run plans directly against `prod` - they do all SQLMesh work in a development environment unique to them. In a standard SQLMesh configuration, this means they need to include their development environment name every time they issue the `plan` command (e.g., `sqlmesh plan dev_tony`).
159+
160+
If your organization works like this, it may be convenient to change the `plan` command's default environment from `prod` to each user's development environment. That way people can issue `sqlmesh plan` without typing the environment name every time.
161+
162+
The SQLMesh configuration `user()` function returns the name of the user currently logged in and running SQLMesh. It retrieves the username from system environment variables like `USER` on MacOS/Linux or `USERNAME` on Windows.
163+
164+
Call `user()` inside Jinja curly braces with the syntax `{{ user() }}`, which allows you to combine the user name with a prefix or suffix.
165+
166+
The example configuration below constructs the environment name by appending the username to the end of the string `dev_`. If the user running SQLMesh is `tony`, the default target environment when they run SQLMesh will be `dev_tony`. In other words, `sqlmesh plan` will be equivalent to `sqlmesh plan dev_tony`.
167+
168+
=== "YAML"
169+
170+
Default target environment is `dev_` combined with the username running SQLMesh.
171+
172+
```yaml
173+
default_target_environment: dev_{{ user() }}
174+
```
175+
176+
=== "Python"
177+
178+
Default target environment is `dev_` combined with the username running SQLMesh.
179+
180+
Retrieve the username with the `getpass.getuser()` function, and combine it with `dev_` in a Python f-string.
181+
182+
```python linenums="1" hl_lines="1 17"
183+
import getpass
184+
import os
185+
from sqlmesh.core.config import (
186+
Config,
187+
ModelDefaultsConfig,
188+
GatewayConfig,
189+
SnowflakeConnectionConfig
190+
)
191+
192+
config = Config(
193+
model_defaults=ModelDefaultsConfig(dialect="duckdb"),
194+
gateways={
195+
"my_gateway": GatewayConfig(
196+
connection=DuckDBConnectionConfig(),
197+
),
198+
},
199+
default_target_environment=f"dev_{getpass.getuser()}",
200+
)
201+
```
202+
154203
### Overrides
155204

156205
Environment variables have the highest precedence among configuration methods, as [noted above](#configuration-files). They will automatically override configuration file specifications if they follow a specific naming structure.
@@ -488,15 +537,15 @@ SELECT 2 AS col
488537
└── Directly Modified:
489538
└── sqlmesh_example__dev.test_model
490539

491-
---
492-
+++
493-
494-
495-
kind FULL
496-
)
497-
SELECT
498-
- 1 AS col
499-
+ 2 AS col
540+
---
541+
+++
542+
543+
544+
kind FULL
545+
)
546+
SELECT
547+
- 1 AS col
548+
+ 2 AS col
500549
```
501550

502551
3. Second (metadata) change in `dev`:
@@ -516,27 +565,27 @@ SELECT 5 AS col
516565
└── Directly Modified:
517566
└── sqlmesh_example__dev.test_model
518567

519-
---
520-
521-
+++
522-
523-
@@ -1,8 +1,9 @@
524-
525-
MODEL (
526-
name sqlmesh_example.test_model,
527-
+ owner "John Doe",
528-
kind FULL
529-
)
530-
SELECT
531-
- 1 AS col
532-
+ 2 AS col
568+
---
569+
570+
+++
571+
572+
@@ -1,8 +1,9 @@
573+
574+
MODEL (
575+
name sqlmesh_example.test_model,
576+
+ owner "John Doe",
577+
kind FULL
578+
)
579+
SELECT
580+
- 1 AS col
581+
+ 2 AS col
533582

534583
Directly Modified: sqlmesh_example__dev.test_model (Breaking)
535584
Models needing backfill:
536585
└── sqlmesh_example__dev.test_model: [full refresh]
537586
```
538587
539-
Even though the second change should have been a metadata change (thus not requiring a backfill), it will still be classified as a breaking change because the comparison is against production instead of the previous development state. This is intentional and may cause additional backfills as more changes are accumulated.
588+
Even though the second change should have been a metadata change (thus not requiring a backfill), it will still be classified as a breaking change because the comparison is against production instead of the previous development state. This is intentional and may cause additional backfills as more changes are accumulated.
540589
541590
542591
### Gateways

‎docs/reference/notebook.md‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -29,9 +29,9 @@ import sqlmesh
2929
If desired, you can create the [quickstart example project](../quick_start.md) with the Python `init_example_project` function. The function requires a default SQL dialect for the project's models; this example uses `snowflake`:
3030

3131
```python
32-
from sqlmesh.cli.example_project import init_example_project
32+
from sqlmesh.cli.project_init import init_example_project
3333

34-
init_example_project("path_to_project_directory", dialect="snowflake")
34+
init_example_project("path_to_project_directory", engine_type="snowflake")
3535
```
3636

3737
Alternatively, create the project with a notebook magic:

0 commit comments

Comments
 (0)