# Определения источников для state:modified

Удалён в v2

Этот флаг удалён в v2. Новое поведение включено всегда. При обновлении удалите этот флаг из `dbt_project.yml`.

| state\_modified\_compare\_more\_unrendered\_values | dbt **v1 Latest** | dbt v1 |
| -------------------------------------------------- | ----------------- | ------ |
| Добавлен                                           | 2024.10           | 1.9.0  |
| Стабилизирован (по умолчанию → `true`)             | 2026.09           | 1.12.0 |
| Удалён                                             | —                 | v2.0   |

к сведению

Необходимо создать каталог состояния с помощью dbt v1.9 или выше либо [dbt на канале обновлений **v1 Latest**](https://docs.getdbt.tech/docs/dbt-versions/dbt-release-tracks.md), а также установить `state_modified_compare_more_unrendered_values` в значение `true` в файле dbt\_project.yml.

Если каталог состояния был создан с использованием более старой версии dbt или если флаг изменения поведения `state_modified_compare_more_unrendered_values` не был установлен или был установлен в значение `false`, вам необходимо пересоздать каталог состояния, чтобы избежать ложных срабатываний при сравнении состояния с `state:modified`.

В dbt v1.12 флаг `state_modified_compare_more_unrendered_values` по умолчанию имеет значение `true`, что сокращает число ложных срабатываний при проверках `state:modified`, особенно когда конфигурации различаются в зависимости от целевого окружения (например, `prod` и `dev`).

Флаг переключает сравнение `state:modified` с отрендеренных значений на значения до рендеринга: для этого при разборе моделей сохраняется `unrendered_config`, а при разборе источников — параметры конфигурации `unrendered_database` и `unrendered_schema`.

примечание

Чтобы этот флаг подействовал, необходимо заново создать каталог состояния (манифест).

## Влияние

Этот флаг без уведомления меняет набор ресурсов, выбираемых с помощью `state:modified`, на который опирается большинство рабочих процессов CI, Slim CI и `dbt build --defer`. Это проявляется двумя способами:

* **Ложное определение ресурсов как изменённых при первом запуске после установки флага в `true`.** Если базовый манифест был создан до установки флага (сохранены отрендеренные значения), а текущий разбор выполняется после изменения настройки (сохраняется исходный текст), каждый узел, в YAML-конфигурации которого есть Jinja, будет определён как `state:modified`, даже если ничего не изменилось. Это приводит к полной пересборке при первом запуске CI после обновления.
* **Выявление дополнительных изменений в дальнейшем.** После того как оба манифеста будут созданы с включённым флагом, `state:modified` будет выявлять случаи, когда два эквивалентных выражения Jinja дают одинаковое значение при рендеринге (например, при переходе с `"{{ env_var('MAT', 'view') }}"` на `view`).

 Чего ожидать

При первом запуске CI или Slim CI с включённым флагом любой узел, в YAML-конфигурации которого используется Jinja (`env_var`, `var`, условный выбор материализации), может быть определён как `state:modified`, даже если ничего не изменилось. Это происходит потому, что в базовом манифесте сохранены отрендеренные значения, а при новом разборе сохраняется исходный текст Jinja — сравниваемые данные различаются способом сериализации, а не фактическими изменениями.

После того как ваше задание в production один раз выполнится на ветке релизов **v1 Latest** и создаст новый базовый манифест, обе стороны сравнения `state:modified` будут использовать один и тот же формат, и лишние различия исчезнут.

Изменять код не требуется. Единственные дополнительные затраты — один цикл пересборки затронутых узлов.

Это новое поведение исправляет недостатки прежнего. Раньше при сравнении незаметно пропускались реальные изменения выражений Jinja (например, переход с `"{{ env_var('MAT', 'view') }}"` на `view` даёт тот же результат рендеринга и никогда не выявлялся). С включённым флагом `state:modified` точнее выявляет изменения в дальнейшем.

Чтобы отключить это поведение, установите флаг в `false` в `dbt_project.yml`:

dbt\_project.yml

```yaml
flags:
  state_modified_compare_more_unrendered_values: false
```

Отключение рекомендуется на время запрета на развёртывание в production, а также если в YAML-конфигурациях вашего проекта активно используется Jinja и однократная пересборка превысит бюджет вычислительных ресурсов CI. В остальных случаях рекомендуется включить этот флаг.