Tipos de objetos compatíveis com DCM Projects

A instrução DEFINE é um comando especial usado exclusivamente em arquivos de definição de DCM project. A sintaxe dela é semelhante à do comando CREATE OR ALTER, mas com as seguintes diferenças importantes:

  • A ordem e o local das instruções DEFINE não importam. O Snowflake coleta e classifica todas as instruções de todos os arquivos de definição durante a execução do projeto.

  • Se você remover uma instrução DEFINE que já foi implantada, o Snowflake descartará o objeto correspondente na próxima vez que você implantar o projeto. O mesmo acontece com as instruções GRANT e ATTACH, que são removidas depois que já foram implantadas.

  • Apenas um subconjunto de tipos de objetos Snowflake é permitido.

  • Todos os objetos devem ser definidos com um nome totalmente qualificado (database.schema.object_name).

  • As referências a outros objetos devem ser feitas com nomes totalmente qualificados.

Os seguintes tipos de objeto são nativamente compatíveis com as instruções DEFINE, GRANT ou ATTACH nos arquivos de definição de DCM Projects.

Banco de dados

🚫 Alterações não permitidas:

Esquema

🚫 Alterações não permitidas:

Tabela

🚫 Alterações não permitidas:

  • Qualquer limitação CREATE OR ALTER, incluindo as seguintes operações:

    • Renomear tabelas

    • Como renomear colunas

    • Reordenar colunas

    • Alterar tipos de colunas para tipos incompatíveis

    • Adicionar otimização de pesquisa a uma tabela ou colunas

    • Adicionar tags e políticas a uma tabela ou colunas

Tabela dinâmica

✅ Alterações permitidas:

Sem uma atualização completa:

  • Warehouse

  • Meta de atraso

Com reinicialização ou uma atualização completa:

  • Modo de atualização

  • Alterações no corpo, incluindo:

    • Descarte de colunas

    • Adicionar colunas ao final

⚠️ Argumentos imutáveis:

  • INITIALIZE

🚫 Alterações não permitidas:

Exibição

🚫 Alterações não permitidas:

Estágio interno

✅ Alterações permitidas:

  • Tabela de diretório

  • Comentário

⚠️ Atributos imutáveis:

  • Tipo de criptografia

Warehouse

⚠️ Atributos imutáveis:

  • INITIALLY_SUSPENDED

Função e função de banco de dados

🚫 Tipos incompatíveis:

  • Função do aplicativo

Grant

🚫 Tipos GRANT incompatíveis:

  • Concessões de APPLICATION ROLE

  • Concessões de CALLER

Nota

Ao remover uma instrução GRANT OWNERSHIP que já foi implantada, os DCM Projects tentam usar a função de proprietário atual para conceder a propriedade de volta ao proprietário do DCM project. Se a função de proprietário do projeto não tiver a função de proprietário do objeto, a propriedade precisará ser transferida de volta manualmente fora dos DCM Projects.

Os DCM Projects só têm conhecimento das concessões que foram definidas e implantadas usando os DCM Projects. As concessões que foram adicionadas fora dos DCM Projects coexistem, e os DCM Projects não as removem.

Função de métrica de dados

As funções de métrica de dados (Data Metric Functions, DMFs) permitem definir as expectativas de qualidade dos dados e anexar essas expectativas a tabelas. Você pode selecionar entre as DMFs de sistema existentes ou escrever as próprias funções de métrica de dados definidas pelo usuário (User-defined Data Metric Functions, UDMFs). Depois disso, você pode anexá-las a tabelas, exibições e tabelas dinâmicas com um relacionamento muitos para muitos. Para obter mais informações, consulte Usar SQL para configurar funções de métricas de dados.

Para anexar funções de métrica de dados, primeiro você precisa adicionar DATA_METRIC_SCHEDULE a cada definição de tabela, tabela dinâmica ou exibição. Por exemplo: DATA_METRIC_SCHEDULE = TRIGGER_ON_CHANGES. O cronograma TRIGGER_ON_CHANGES não está disponível para exibições.

Os nomes das expectativas definidos pelo usuário devem ser exclusivos por projeto e anexo.

A definição de expectativas é opcional, mas recomendada, ao anexar DMFs a colunas de tabela. As DMFs anexadas sem expectativas definidas não são consideradas ao executar EXECUTE DCM PROJECT <my_project> TEST ALL.

✅ Alterações permitidas:

  • Definindo UDMFs (funções de métrica de dados definidas pelo usuário)

  • Anexando DMFs de sistema e UDMFs a tabelas, exibições ou tabelas dinâmicas dentro e fora de um DCM project

  • Definindo expectativas de dados para colunas de tabela

Exemplo:

Um exemplo de definição de UDMF:

DEFINE DATA METRIC FUNCTION DCM_DEMO.TESTS.INVENTORY_SPREAD(
  TABLE_NAME TABLE(
    COLUMN_VALUE number
  )
)
  RETURNS number
AS
$$
  SELECT
    MAX(COLUMN_VALUE) - MIN(COLUMN_VALUE)
  FROM
    TABLE_NAME
  WHERE
    COLUMN_VALUE IS NOT NULL
$$;

Um exemplo de anexação de DMF de sistema com expectativa:

ATTACH DATA METRIC FUNCTION SNOWFLAKE.CORE.MIN
  TO TABLE DCM_PROJECT_{{db}}.RAW.INVENTORY
  ON (IN_STOCK)
  EXPECTATION MIN_10_ITEMS_INVENTORY (value > 10);

Um exemplo de anexação de UDMF com expectativa:

ATTACH DATA METRIC FUNCTION DCM_DEMO.TESTS.INVENTORY_SPREAD
  TO TABLE DCM_PROJECT_{{db}}.RAW.INVENTORY
  ON (IN_STOCK)
  EXPECTATION EVEN_ITEM_INVENTORY (VALUE < 50);

Para ver todas as DMFs de sistema disponíveis, consulte SHOW DATA METRIC FUNCTIONS IN DATABASE SNOWFLAKE.

Tarefa

  • Quando alterações de definição são implementadas para uma tarefa que já foi iniciada, o Snowflake suspende automaticamente a tarefa (ou a respectiva tarefa raiz) de modo temporário, aplica a alteração e depois a retoma.

  • As tarefas recém-implantadas são suspensas por padrão.

🚫 Alterações não permitidas:

Limitações nas instruções CREATE OR ALTER TASK. Consulte CREATE TASK para obter mais informações.

Função SQL

🚫 Alterações não permitidas:

Limitações nas instruções CREATE OR ALTER. Consulte CREATE FUNCTION para obter mais informações.

Tag

🚫 Atributos incompatíveis:

  • Propagar

Anexação de tags, políticas de mascaramento e políticas de acesso a linhas (incompatíveis)

Tags, políticas de mascaramento e políticas de acesso a linhas não podem ser adicionadas a definições de colunas de tabela nos DCM Projects.

  • É possível anexar políticas de mascaramento e de acesso a linhas manualmente fora dos DCM Projects.

  • As definições de DCM Projects dos objetos de tabela ignoram todas as políticas de mascaramento ou de acesso a linhas anexadas. Elas não são revogadas pela reimplantação das definições de tabela, mesmo quando essas definições não contêm as políticas.