# allow\_clones

profiles.yml

```yaml
my_project:
  outputs:
    prod:
      type: snowflake
      # ... other connection settings
      allow_clones: true | false
  target: dev
```

## Определение

`allow_clones` — это настройка уровня профиля, которая определяет, разрешено ли dbt State клонировать таблицы в целевое окружение. По умолчанию dbt State может клонировать таблицу из любого окружения — в том числе из dev в prod, если данные и логика совпадают. Такое поведение предусмотрено намеренно: если вы построили модель в dev и ничего не изменилось, клонирование в prod экономит вычислительные ресурсы по сравнению с повторным построением.

Настройка `allow_clones: false` для целевого окружения указывает dbt State пропускать кандидатов на клонирование и вместо этого выполнять полное построение, даже если в другом целевом окружении существует подходящая таблица.

Эта настройка влияет только на то целевое окружение, для которого она задана. Другие целевые окружения в том же профиле не затрагиваются.

Пользователям dbt platform следует задать `allow_clones` как [расширенный атрибут](https://docs.getdbt.tech/docs/dbt-platform-environments.md#extended-attributes) в [профиле подключения](https://docs.getdbt.tech/docs/platform/about-profiles.md) для окружения развертывания:

```yaml
allow_clones: true | false
```

## Значение по умолчанию

`true`. Если настройка не указана, клонирование включено, и dbt State клонирует таблицы из любого окружения, где существует подходящая таблица.

## Когда следует отключать

предупреждение

Настройка `allow_clones: false` снижает выигрыш в эффективности от использования dbt State. Для узлов, которые dbt State в противном случае клонировал бы, вместо этого выполняется полное построение. Оцените, необходимо ли такое ограничение для вашего окружения.

Как правило, задавать `allow_clones: false` не требуется. dbt State выполняет клонирование только тогда, когда SQL-логика исходной таблицы совпадает, а данные в ней новее. Поскольку это определяется по дате изменения таблицы (а не путем прямого сравнения ее содержимого), ручное изменение таблицы вне dbt может обновить дату ее изменения, хотя ее содержимое фактически не будет соответствовать результату полного построения. Оставлять `allow_clones` включенным безопасно, если вы всегда изменяете содержимое таблиц через dbt, а не редактируете таблицы вручную

Отключение `allow_clones` полезно в окружениях с нормативными ограничениями, где политика запрещает запись любых данных из схемы разработки в продакшен независимо от их корректности (например, в окружениях с требованиями к управлению данными или аудиту, где источником создания таблицы в продакшене должен быть SQL-запрос, выполненный в хранилище данных, а не клонирование).

## Связанная документация

* [О dbt State](https://docs.getdbt.tech/docs/deploy/dbt-state-about.md)
* [Настройки dbt State](https://docs.getdbt.tech/reference/resource-configs/dbt-state-configs.md)