Перейти к основному содержимому

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

Удалён в v2

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

state_modified_compare_more_unrendered_valuesdbt v1 Latestdbt v1
Добавлен2024.101.9.0
Стабилизирован (по умолчанию → true)2026.091.12.0
Удалён—v2.0
к сведению

Необходимо создать каталог состояния с помощью dbt v1.9 или выше либо dbt на канале обновлений v1 Latest, а также установить 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
flags:
  state_modified_compare_more_unrendered_values: false

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

Нашли ошибку?

0
Loading