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
Standalone audits are defined independently rather than being attached to a specific model. They specify the models they depend on using the `depends_on` property.
164
+
165
+
Unlike model-level audits, standalone audits can be used to validate data across one or more models without being associated with a single model.
166
+
167
+
Standalone audits run as scheduled nodes during both `sqlmesh plan` and `sqlmesh run`.
168
+
169
+
```sql linenums="1"
170
+
AUDIT (
171
+
name assert_item_price_is_not_null,
172
+
dialect spark,
173
+
standalone TRUE,
174
+
depends_on (
175
+
sushi.items
176
+
)
177
+
);
178
+
179
+
SELECT*
180
+
FROMsushi.items
181
+
WHERE
182
+
ds BETWEEN @start_ds AND @end_ds
183
+
AND price IS NULL;
184
+
```
185
+
186
+
In this example, the audit checks that the `price` column in `sushi.items` does not contain `NULL` values for the selected date range.
187
+
188
+
Standalone audits can declare dependencies using the `depends_on` property. SQLMesh can often infer dependencies directly from the audit query, but using `depends_on` is recommended when inference isn't sufficient.
189
+
190
+
!!! note
191
+
192
+
Standalone audits are non-blocking only. Because they are not associated with a single model, SQLMesh cannot determine which model should be blocked if the audit fails.
162
193
## Built-in audits
163
194
SQLMesh comes with a suite of built-in generic audits that cover a broad set of common use cases. Built-in audits are blocking by default, but they all have non-blocking counterparts which you can use by appending `_non_blocking` - see [Non-blocking audits](#non-blocking-audits).
Copy file name to clipboardExpand all lines: docs/concepts/plans.md
+6Lines changed: 6 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -109,6 +109,12 @@ For context, every model has a start date. The start can be specified in [the mo
109
109
110
110
Because the prod environment supports business operations, prod plans ensure every model is backfilled from its start date until the most recent completed time interval. Due to that restriction, the `plan` command's `--start` and `--end` options are not supported for regular plans against prod. The options are supported for [restatement plans](#restatement-plans) against prod to allow re-processing a subset of existing data.
111
111
112
+
!!! note "Explicit execution time"
113
+
114
+
"The most recent completed time interval" is measured relative to the plan's *execution time*, which defaults to now. If you pass an explicit `--execution-time` that is later than the intervals already loaded in prod, the plan extends its end date up to that time and backfills the intervals in between.
115
+
116
+
For example, if a daily model in prod is loaded through 2025-12-25, running `sqlmesh plan --execution-time '2025-12-28'` backfills the missing 2025-12-26 and 2025-12-27 intervals.
117
+
112
118
Non-prod plans are typically used for development, so their models can optionally be backfilled for any date range with the `--start` and `--end` options. Limiting the date range makes backfills faster and development more efficient, especially for incremental models using large tables.
Copy file name to clipboardExpand all lines: docs/guides/linter.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -74,6 +74,7 @@ Here are all of SQLMesh's built-in linting rules:
74
74
|`invalidselectstarexpansion`| Correctness | The query's top-level selection may be `SELECT *`, but only if SQLMesh can expand the `SELECT *` into individual columns |
75
75
|`noselectstar`| Stylistic | The query's top-level selection may not be `SELECT *`, even if SQLMesh can expand the `SELECT *` into individual columns |
76
76
|`nomissingaudits`| Governance | SQLMesh did not find any `audits` in the model's configuration to test data quality. |
77
+
|`nomissingunittest`| Governance | SQLMesh did not find any `unit tests` associated with the model to test |
77
78
78
79
### User-defined rules
79
80
@@ -126,6 +127,14 @@ Error: Linter detected errors in the code. Please fix them before proceeding.
126
127
127
128
Use `sqlmesh lint --help` for more information.
128
129
130
+
You can pass `--local` to run lint without loading state from the configured state connection:
131
+
132
+
```bash
133
+
$ sqlmesh lint --local
134
+
```
135
+
136
+
This can make linting faster in repositories where all referenced models are loaded from local files. In multi-repository setups, or when linting only a subset of projects, `--local` may cause additional linting errors because SQLMesh will not resolve references or schemas from models that exist only in remote state.
137
+
129
138
130
139
## Applying linting rules
131
140
@@ -258,4 +267,4 @@ You may specify that a rule's violation should not error and only log a warning
258
267
)
259
268
```
260
269
261
-
SQLMesh will raise an error if the same rule is included in more than one of the `rules`, `warn_rules`, and `ignored_rules` keys since they should be mutually exclusive.
270
+
SQLMesh will raise an error if the same rule is included in more than one of the `rules`, `warn_rules`, and `ignored_rules` keys since they should be mutually exclusive.
Copy file name to clipboardExpand all lines: docs/reference/configuration.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -114,7 +114,7 @@ Formatting settings for the `sqlmesh format` command and UI.
114
114
|`normalize`| Whether to normalize SQL (Default: False) | boolean | N |
115
115
|`pad`| The number of spaces to use for padding (Default: 2) | int | N |
116
116
|`indent`| The number of spaces to use for indentation (Default: 2) | int | N |
117
-
|`normalize_functions`|Whether to normalize function names. Supported values are: 'upper' and 'lower' (Default: None) | string | N |
117
+
|`normalize_functions`|How to normalize function name casing. `false` (default) preserves the casing of custom and audit function names as written; `"upper"` uppercases all function names; `"lower"` lowercases all function names; `true` defers to SQLGlot's generator default and uppercases all function names including custom ones; `null` (or omitting the key) is excluded during serialization and therefore takes the same `false` default path — it does **not** defer to SQLGlot's generator default. Note: SQLGlot built-in function names may still be canonicalized by the parser regardless of this setting. | string \| boolean \| null| N |
118
118
|`leading_comma`| Whether to use leading commas (Default: False) | boolean | N |
119
119
|`max_text_width`| The maximum text width in a segment before creating new lines (Default: 80) | int | N |
120
120
|`append_newline`| Whether to append a newline to the end of the file (Default: False) | boolean | N |
0 commit comments