|dcm|ファイルとテンプレート¶

プロジェクト定義とプロジェクトオブジェクト間のマップ¶

|dcm|定義ファイルは、特定の|dcm-object|オブジェクトに厳密に関連付けられていません。同じ定義セットを使用して、異なるSnowflakeアカウントで、または異なる構成プロファイルを参照することによって、複数のプロジェクトにデプロイできます。たとえば、次の図表に示すように、リポジトリブランチ上の同じ定義ファイルをDEVとPRODの両方のアカウントにデプロイできます。

同様に、異なるパスの定義ファイルを参照して|dcm|オブジェクトを実行できます。たとえば、CI/CD自動化はメインブランチから定義をデプロイでき、同じプロジェクトに対してローカル定義ファイルから手動でPLANを実行して、定義が最新のデプロイからどのように分岐するかを確認できます。このアプローチは、他のブランチやローカルパスからのアドホックな手動デプロイにも使用できます。

マクロ¶

マクロファイルは、:file:`macros`フォルダーとそのサブフォルダーにある任意のSQLファイルです。これらにはマクロのみを含めることができます。

マクロファイルを含む|dcm-object|のディレクトリ構造の例は次のとおりです。

My_dcm_project
 |_ manifest.yml
 |_ sources
    |_ definitions
       |_ my_definitions.sql
    |_ macros
       |_ my_global_macros.sql

通常のプログラミング言語の関数と同様に、マクロはよく使用されるコードを再利用可能な関数に整理し、反復を避けてDRY（Don't Repeat Yourself）原則に従うのに役立ちます。|dcm|のマクロは、次の例外を除いて、`Jinja2マクロ<https://jinja.palletsprojects.com/en/stable/templates/#macros>`_と同じように機能します。

• :file:`macros`フォルダー内のマクロファイルの専用場所に配置されます。

• マクロファイルで定義されたマクロは、他のソースファイルで自動的に表示されます。Jinjaの`import<https://jinja.palletsprojects.com/en/stable/templates/#import>`_タグの使用は許可されていません。

• 同じ名前のマクロの重複定義は検出され、拒否されます。

テンプレートコメント¶

SQLコマンドでは、コードの前に``--``を追加して行をコメントアウトできます。Jinjaは引き続きSQLコード内の変数を処理しますが、SQLコメントは残します。

たとえば、次のJinjaコードは、

-- hello {{ project_owner_role }}

次のようにレンダリングされます。

-- hello DCM_DEVELOPER

コメントアウトされたコマンドはSQLでは実行されません。テンプレートコメントを使用すると、SQLコードに影響を与えずにJinjaテンプレートをデバッグできます。

次の例に示すように、レンダリング時にJinjaコードを無視するには、開始括弧と終了括弧の内側に``#``を追加します。

{# This Jinja comment will not appear in the rendered output. #}

構成¶

オブジェクト定義でテンプレートを使用する場合には、以下のオプションがあります。

• 実行時、変数に値を割り当てる。

• manifest.yml`の``templating: configurations:``でさまざまな構成プロファイルを定義する。各ターゲットは``templating_config``を通じて構成を参照できます。詳細については、 :ref:`label-dcm_projects_files_configurations をご参照ください。

  構成プロファイルが定義され、ターゲットが``templating_config``を通して1つを参照する場合、そのターゲットを使用すると構成が自動的に適用されます。例については、 |dcm-object|の計画 をご参照ください。

  |dcm|の構成プロファイルの主な使用例は、異なる環境をターゲットにすることです。構成プロファイルでは、次を実行できます。

  • 同じコードを複数の環境にデプロイできます。

  • 本番コードを非本番環境において小規模にテストできます。

  • 同じアカウントで複数の分離された環境を維持できます。

  すべてのテンプレート化構成をターゲットプロファイルから参照させる必要はありません。未使用の構成を維持したまま、ターゲットのテンプレート化構成をあるものから別のものに切り替えることができます。

• 構成間で共通の変数の繰り返しを回避するために、``templating: defaults:``で共有デフォルト値を定義します。詳細については、 プロジェクトのテンプレート化構成 をご参照ください。

• CLIの``--variable``フラグを使用して、実行時に特定の変数を1回限りの値で上書きします。

変数は、グローバルデフォルト < 構成変数 < ランタイム実行変数という3つの階層で解決されます。

辞書¶

|dcm|テンプレート化は、変数値としてのディクショナリをサポートし、複雑なマルチテナントまたはマルチリソースデプロイメントのための構造化された構成を可能にします。

関連する構成の詳細をディクショナリにグループ化すると、次のような利点があります。

• きめ細かな制御：バリエーションごとに一意のロジックを記述することなく、個々のリソースにウェアハウスのサイズ、保持ポリシー、付与などの特定の設定を適用できます。

• よりクリーンなコードベース：反復的なハードコードされたスクリプトを、構成に基づいて適応する動的ループに置き換えることができます。

• スケーラビリティ:デプロイメントパイプラインをリファクタリングするのではなく、構成にエントリを追加して、新しいチームやリソースをオンボーディングします。

templating:
  defaults:
    user: "GITHUB_ACTIONS_SERVICE_USER"
    wh_size: "X-SMALL"
  configurations:
    PROD:
      env_suffix: ""
      project_owner_role: "DCM_PROD_DEPLOYER"
      teams:
        - name: "Marketing"
          wh_size: "MEDIUM"
          data_retention_days: 14
          needs_sandbox_schema: true
        - name: "Finance"
          wh_size: "X-LARGE"
          data_retention_days: 90
          needs_sandbox_schema: false
        - name: "HR"
          data_retention_days: 30
          needs_sandbox_schema: false

-- loop through team dictionaries
{% for team in teams %}
    {% set team_name = team.name | upper %}

    -- inject dictionary values directly into object properties
    define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}
        comment = 'using JINJA dictionary values'
        data_retention_time_in_days = {{ team.data_retention_days }};

    -- pass the name to your macro
    {{ create_team_roles(team_name) }}

    define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.PRODUCTS(
        ITEM_NAME varchar,
        ITEM_ID varchar,
        ITEM_CATEGORY array
    )
    data_metric_schedule = 'TRIGGER_ON_CHANGES';

    {% if team_name == 'HR' %}
        define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.EMPLOYEES(
            NAME varchar,
            ID int
        )
        comment = 'This table is only created in HR';
    {% endif %}

    -- use dictionary booleans to deploy optional infrastructure
    {% if team.needs_sandbox_schema | default(false) %}
        define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}_SANDBOX
            comment = 'Sandbox schema defined via dictionary flag'
            data_retention_time_in_days = 1;
    {% endif %}

{% endfor %}