Pacote 2022_07

Este tópico descreve as seguintes mudanças de comportamento (se houver) do mês:

  • Recursos que foram descontinuados.

  • Pacote de mudanças que foram ativadas.

  • Outras mudanças não inclusas no pacote que foram implementadas.

Se tiver alguma dúvida sobre estas mudanças, entre em contato com o suporte Snowflake.

Para obter mais detalhes sobre os novos recursos, melhorias e correções introduzidos neste mês, consulte Outubro de 2022.

Importante

Salvo indicação em contrário, estas mudanças estão no pacote 2022_07, que foi habilitado por padrão na versão 6.35.

Neste tópico:

Mudanças de SQL — Comandos e funções

Bancos de dados e esquemas: Descarte ou substituição não permitida se isso resultar em referências pendentes para políticas e tags

O comportamento das operações para descartar ou substituir um banco de dados/esquema com relação a uma política de mascaramento, tag e coluna protegida em uma tabela mudou como se segue:

Anteriormente:

Quando a tag e a política estão no mesmo esquema e a tabela está em um esquema diferente, Snowflake permitiu as operações DROP e REPLACE no esquema/banco de dados que contém uma tag e uma política de mascaramento quando a coluna protegida na tabela existe em um esquema/banco de dados diferente.

O comportamento se aplicava aos quatro comandos seguintes:

Atualmente:

Se o mesmo cenário ocorrer agora, Snowflake não permite as operações DROP e REPLACE no esquema/banco de dados que contém uma tag e uma política de mascaramento quando a coluna protegida na tabela existe em um esquema/banco de dados diferente.

Como resultado, o comportamento dos quatro comandos listados acima mudou.

Por exemplo:

  • Uma tag chamada t1 e uma política de mascaramento chamada p1 existem no esquema chamado governance.tags.

  • A política de mascaramento p1 é atribuída à tag t1 (isto é, política de mascaramento baseada em tags).

  • A tag t1 é atribuída a uma tabela chamada finance.accounting.customers.

Anteriormente, Snowflake permitia a operação DROP SCHEMA no esquema governance.tags e a operação DROP DATABASE no banco de dados governance enquanto a tag t1 era atribuída à tabela finance.accounting.customers.

Agora, Snowflake não permite que nenhuma das operações seja realizada enquanto a tag t1 estiver atribuída à tabela. Dependendo da operação tentada, Snowflake retorna uma das seguintes mensagens de erro:

  • DROP DATABASE e CREATE OR REPLACE DATABASE:

    Cannot drop or replace database because: Tag governance.tags.tag1 used by schema finance.accounting in another database

  • DROP SCHEMA e CREATE OR REPLACE SCHEMA:

    Cannot drop or replace schema because: Tag governance.tags.tag1 used by another schema finance.accounting

Comando CREATE MATERIALIZED VIEW: cláusulas do Time Travel que não são mais permitidas

Uma limitação das exibições materializadas é que o Time Travel não é suportado. No entanto, ao executar o comando CREATE MATERIALIZED VIEW, foi possível especificar uma cláusula de Time Travel (por exemplo, AT) para a tabela base da exibição.

A especificação de uma cláusula de Time Travel em CREATE MATERIALIZED VIEW agora resulta em um erro.

Anteriormente:

A especificação de uma cláusula de Time Travel em CREATE MATERIALIZED VIEW não produziu um erro.

Por exemplo, as seguintes instruções executadas com sucesso sem nenhum erro:

  • Exemplo 1:

    create or replace materialized view mv as select * from basetbl at(offset => -2);
    
    Copy
  • Exemplo 2:

    create or replace materialized view mv as select * from basetbl at(timestamp => $ts);
    
    Copy
  • Exemplo 3:

    create or replace materialized view mv as select * from basetbl at(statement => $uuid_dml);
    
    Copy
Atualmente:

A especificação de uma cláusula de Time Travel em CREATE MATERIALIZED VIEW produz agora o seguinte erro:

002274 (42601): SQL compilation error: Invalid materialized view: Time travel on base table in line X at position Y.

Mudanças de SQL — Exibições de uso e exibições Information Schema/funções de tabela

Exibição GRANT_TO_ROLES (Account Usage): mudança na exibição

As seguintes mudanças foram introduzidas na exibição ACCOUNT_USAGE.GRANTS_TO_ROLES.

Anteriormente:

A saída da exibição incluiu a concessão de privilégios a funções em tabelas temporárias.

Atualmente:

A saída da exibição não inclui a concessão de privilégios a funções em tabelas temporárias.

Mudanças no data lake

Comando CREATE EXTERNAL TABLE: partições especificadas pelo usuário e metadados automaticamente atualizados

Definir as partições em uma tabela externa como especificadas pelo usuário significa que você escolhe adicionar e remover as partições seletivamente em vez de adicionar automaticamente partições para todos os novos arquivos em um local de armazenamento externo que corresponda a uma expressão. Este tipo de partição é especificado pela inclusão do parâmetro PARTITION_TYPE = USER_SPECIFIED quando se cria uma tabela externa. A partição especificada pelo usuário não oferece suporte à atualização automática de metadados de tabelas externas.

Quando uma instrução CREATE EXTERNAL TABLE é executada com os parâmetros PARTITION_TYPE = USER_SPECIFIED e AUTO_REFRESH = TRUE definidos, o comportamento mudou da seguinte forma:

Anteriormente:

A instrução CREATE EXTERNAL TABLE foi bem sucedida; entretanto, qualquer notificação de evento recebida do armazenamento em nuvem para a tabela externa (por exemplo, mensagens de “novo objeto”) produziu um erro.

Atualmente:

A instrução CREATE EXTERNAL TABLE retorna um erro do usuário.

Função GET_DDL: retorna o parâmetro TABLE_FORMAT para tabelas externas no Delta Lake

Quando a entrada para a função GET_DDL é uma tabela externa que faz referência a uma tabela do Delta Lake, a instrução CREATE EXTERNAL TABLE retornada pela função mudou da seguinte forma:

Anteriormente:

A instrução omitiu o parâmetro TABLE_FORMAT = DELTA que identifica a tabela externa como referenciando uma tabela do Delta Lake.

Atualmente:

A instrução inclui o parâmetro TABLE_FORMAT = DELTA:

Mudanças de extensibilidade

Snowpark para Python: Retorna erros antecipadamente ao adicionar pacotes inválidos

Ao adicionar um pacote Python a uma sessão do Snowpark Python, o usuário recebe uma mensagem de erro se o pacote ou sua versão especificada não for suportada pelo Snowflake.

A hora em que a mensagem de erro é recebida foi alterada para ser mais cedo:

Anteriormente:

O erro foi recebido somente quando o usuário tentou registrar um UDF ou um procedimento armazenado.

Atualmente:

O erro ocorre mais cedo, quando são usados pacotes add_packages para adicionar o pacote Python.

Por exemplo, chamar "session.add_packages('numpy==21.21.21')" resulta em "ValueError" porque a versão do pacote não é válida.

Snowpark para Scala e Java: Mudança para tipos de membros em DeleteResult, MergeResult e UpdateResult

Nos APIs do Snowpark Scala e Java, as classes DeleteResult, MergeResult e UpdateResult fornecem métodos de valor e Getter que retornam o número de linhas que foram inseridas, atualizadas e excluídas:

  • No API do Snowpark Scala, estes membros de valor são nomeados:

    • rowsInserted

    • multiJoinedRowsUpdated

    • rowsUpdated

    • rowsDeleted

  • No API do Snowpark Java, estes métodos Getter são nomeados:

    • getRowsInserted

    • getMultiJoinedRowsUpdated

    • getRowsUpdated

    • getRowsDeleted

Na versão 1.7.0 da Biblioteca Snowpark para Scala e Java, os tipos destes membros de valor e os tipos de retorno destes métodos Getter mudaram:

Anterior a 1.7.0:
  • No API Scala, o tipo é Int.

  • No API Java, o tipo é int.

Começando com 1.7.0:
  • No API Scala, o tipo é Long.

  • No API Java, o tipo é long.