Bundle 2022_04

Ce chapitre décrit les changements de comportement suivants (le cas échéant) pour le mois :

  • Les fonctionnalités devenues obsolètes.

  • Les changements groupés qui ont été activés.

  • Les autres changements non groupés qui ont été mis en œuvre.

Si vous avez des questions sur ces modifications, veuillez contacter le support Snowflake.

Pour obtenir des détails sur les nouvelles fonctionnalités, les améliorations et les corrections introduites ce mois-ci, voir Juillet 2022.

Important

Sauf indication contraire, ces modifications sont présentes dans le bundle 2022_04, qui a été activé par défaut dans la version 6.25.

Dans ce chapitre :

Changements SQL — Général

Clonage d’un schéma permanent avec des tables enfant permanentes pour créer un schéma transitoire

Lorsqu’un schéma transitoire est créé en clonant un schéma permanent, les objets enfants du schéma sont également clonés.

Le type des objets de table enfant dans le schéma transitoire cloné a changé comme suit :

Précédemment

Toutes les tables permanentes du schéma source ont été clonées en tant que tables permanentes dans le schéma cible, et toutes les tables transitoires ont été clonées en tant que tables transitoires.

Actuellement

Toutes les tables permanentes du schéma source sont clonées en tant que tables transitoires dans le schéma cible.

Changements SQL — Commandes et fonctions

Commande SHOW EXTERNAL TABLES : nouvelles colonnes dans la sortie

Les deux nouvelles colonnes suivantes ont été ajoutées à la sortie de la commande SHOW EXTERNAL TABLES :

  • TABLE_FORMAT

  • LAST_REFRESH_DETAILS

Pour aider à limiter l’impact de ce changement, les colonnes ont été ajoutées en tant que dernières colonnes dans la sortie.

Les colonnes ont été ajoutées pour prendre en charge les fonctionnalités futures.

Commande SHOW SCHEMAS : modifications de la sortie RETENTION_TIME pour les schémas

La valeur de la colonne RETENTION_TIME dans la sortie de la commande SHOW SCHEMAS pour les schémas d’une base de données dont le paramètre DATA_RETENTION_TIME_IN_DAYS est 0 a été modifiée comme suit :

Précédemment

La valeur de RETENTION_TIME était une chaîne vide.

Actuellement

La valeur de RETENTION_TIME est 0.

Commande SHOW WAREHOUSES : nouvelles colonnes dans la sortie

Les nouvelles colonnes suivantes ont été ajoutées à la sortie de la commande SHOW WAREHOUSES pour les comptes pour lesquels la fonction Query Acceleration Service est activée :

Nom de la colonne

Description

enable_query_acceleration

Si la fonction Service Query Acceleration est activée pour l’entrepôt.

query_acceleration_max_scale_factor

Facteur d’échelle maximum pour le service d’accélération des requêtes.

Les nouvelles colonnes ont été ajoutées entre les colonnes comment et resource_monitors. Les requêtes qui dépendent de la sortie de la commande SHOW WAREHOUSES doivent utiliser le nom de la colonne plutôt qu’un index codé en dur pour la sortie de la colonne.

Fonction GET_DDL : modifications de la sortie pour les fonctions et les procédures

Actuellement, lorsque vous appelez la fonction GET_DDL pour obtenir l’instruction DDL qui a créé une UDF, une fonction externe ou une procédure stockée, le nom de la fonction ou de la procédure est placé entre guillemets, même si le nom respecte les règles relatives aux identificateurs d’objet non cités.

Cette sortie a été modifiée dans les cas où vous renvoyez le nom pleinement qualifié de la fonction ou de la procédure (c’est-à-dire lorsque vous appelez GET_DDL avec TRUE comme troisième argument) :

Précédemment

GET_DDL a renvoyé le nom de la fonction ou de la procédure entre guillemets :

+-------------------------------------------------------+
| GET_DDL('FUNCTION', 'MYFUNC(FLOAT)', TRUE)            |
|-------------------------------------------------------|
| CREATE OR REPLACE FUNCTION MYDB.MYSCHEMA."MYFUNC" ... |
+-------------------------------------------------------+
Copy
Actuellement

GET_DDL renvoie le nom de la fonction ou de la procédure sans les guillemets :

+-------------------------------------------------------+
| GET_DDL('FUNCTION', 'MYFUNC(FLOAT)', TRUE)            |
|-------------------------------------------------------|
| CREATE OR REPLACE FUNCTION MYDB.MYSCHEMA.MYFUNC ...   |
+-------------------------------------------------------+
Copy

Notez que cela ne concerne que les cas dans lesquels vous renvoyez le nom entièrement qualifié de la fonction ou de la procédure. Si vous omettez le troisième argument de GET_DDL (ou spécifiez FALSE), GET_DDL renvoie le nom de la fonction ou de la procédure entre guillemets :

+-------------------------------------------------------+
| GET_DDL('FUNCTION', 'MYFUNC(FLOAT)')                  |
|-------------------------------------------------------|
| CREATE OR REPLACE FUNCTION "MYFUNC" ...               |
+-------------------------------------------------------+
Copy

Changements SQL — Vues d’utilisation et vues Information Schema/Fonctions de table

Vue POLICY_REFERENCES (Account Usage) : nouvelles colonnes

Pour prendre en charge les politiques de masquage basées sur les balises, la vue POLICY_REFERENCES (dans le schéma ACCOUNT_USAGE de la base de données partagée SNOWFLAKE) comprend désormais les colonnes suivantes :

  • nom_de_la_balise

  • tag_database

  • tag_schema

  • policy_status

Avec ces nouvelles colonnes, notez ce qui suit :

  • Les colonnes, leurs types de données et leurs descriptions correspondent aux mêmes colonnes dans la fonction de table POLICY_REFERENCES Information Schema.

  • Pour les lignes existantes dans la vue, Snowflake renvoie NULL pour les nouvelles colonnes.

  • Cette mise à jour ne fait qu’ajouter de nouvelles colonnes à la vue. Vous pouvez utiliser la fonction de politique de masquage basée sur les balises sans activer ce changement de comportement à condition que votre compte Snowflake soit Enterprise Edition (ou supérieur).

Pour aider à limiter l’impact de ce changement, ces nouvelles colonnes ont été ajoutées en tant que dernières colonnes dans la sortie.

Vue QUERY_HISTORY (Account Usage) : nouvelles colonnes

Les nouvelles colonnes suivantes ont été ajoutées à la vue QUERY_HISTORY Account Usage :

Nom de la colonne

Type de données

Description

QUERY_ACCELERATION_BYTES_SCANNED

NUMBER

Nombre d’octets analysés par le service d’accélération des requêtes. La valeur par défaut est 0 si la requête n’a pas été accélérée.

QUERY_ACCELERATION_PARTITIONS_SCANNED

NUMBER

Nombre de partitions analysées par le service d’accélération des requêtes. La valeur par défaut est 0 si la requête n’a pas été accélérée.

QUERY_ACCELERATION_UPPER_LIMIT_SCALE_FACTOR

NUMBER

Facteur d’échelle de limite supérieure dont aurait bénéficié une requête. La valeur par défaut est 0 si la requête n’a pas été accélérée.

Pour aider à limiter l’impact de ce changement, les nouvelles colonnes ont été ajoutées en tant que dernières colonnes dans la sortie.

Modifications des pipelines de données

Commande ALTER STREAM : la définition du paramètre APPEND_ONLY ou INSERT_ONLY n’est plus autorisée

Le type de flux ne peut pas être modifié après la création d’un flux. Le type est défini comme suit lorsque le flux est créé :

  • Définissez APPEND_ONLY = TRUE pour créer un flux d’ajout uniquement.

  • Définissez INSERT_ONLY = TRUE pour créer un flux à insertion uniquement.

  • Omettez les deux paramètres pour créer un flux standard (delta).

La tentative de modifier le type d’un flux existant à l’aide de la commande ALTER STREAM renvoie désormais une erreur utilisateur.

Pour modifier le type d’un flux existant, vous devez recréer le flux (en utilisant CREATE OR REPLACE STREAM) et spécifier le type de flux souhaité.

Tâches : modifications du message d’erreur

Les messages d’erreur utilisateur renvoyés lors de la tentative d’actions SQL non valides liées à des tâches sans serveur (c’est-à-dire des tâches qui s’exécutent en utilisant des ressources informatiques gérées par Snowflake) ont été modifiés comme suit :

  • Cas d’utilisation 1 : à l’aide d’un rôle qui ne bénéficie pas du privilège global EXECUTE MANAGED TASK, exécutez une instruction CREATE TASK et omettez le paramètre WAREHOUSE.

    Texte d’erreur précédent

    Missing option(s): [WAREHOUSE]

    Texte d’erreur actuel

    WAREHOUSE not specified and missing serverless task privilege to create task {task name}. To create it as a user-managed task, specify a WAREHOUSE. To create it as a serverless task, execute the CREATE TASK command with a role that has been granted the 'EXECUTE MANAGED TASK' account-level privilege.

  • Cas d’utilisation 2 : à l’aide d’un rôle qui ne bénéficie pas du privilège global EXECUTE MANAGED TASK, clonez une tâche sans serveur (ou une base de données ou un schéma qui contient une ou plusieurs tâches sans serveur) en utilisant la commande CREATE … CLONE appropriée.

    Texte d’erreur précédent

    Task {task name} requires a warehouse.

    Texte d’erreur actuel

    WAREHOUSE not specified and missing serverless task privilege to create task {task name}. To create it as a user-managed task, specify a WAREHOUSE. To create it as a serverless task, execute the CLONE command with a role that has been granted the 'EXECUTE MANAGED TASK' account-level privilege.

  • Cas d’utilisation 3 : à l’aide d’un rôle qui ne dispose pas du privilège global EXECUTE MANAGED TASK, annulez le paramètre WAREHOUSE d’une tâche existante qui s’exécute en utilisant des ressources informatiques gérées par le client (à l’aide d’une instruction ALTER TASK … UNSET WAREHOUSE).

    Texte d’erreur précédent

    Task {task name} requires a warehouse.

    Texte d’erreur précédent

    Cannot UNSET WAREHOUSE on task {task_name} because its owner role has not been granted the 'EXECUTE MANAGED TASK' account-level privilege. Grant this privilege to the role or use GRANT OWNERSHIP to change the task's owner role to one with this privilege.

  • Cas d’utilisation 4 :

    1. en utilisant un rôle auquel est accordé le privilège global EXECUTE MANAGED TASK (ainsi que d’autres privilèges minimums), créez et reprenez une tâche sans serveur.

    2. Le privilège EXECUTE MANAGED TASK est révoqué du rôle propriétaire (le rôle qui possède le privilège OWNERSHIP sur la tâche).

    3. La tâche n’est pas mise en pause et lance sa prochaine exécution planifiée, ou un utilisateur ayant le rôle de propriétaire exécute la commande EXECUTE TASK pour tenter de lancer une exécution de tâche.

    Texte d’erreur précédent

    Cannot execute task, USAGE privilege on the task's warehouse must be granted to the owner role

    Texte d’erreur actuel

    Impossible d’exécuter la tâche, le privilège EXECUTE MANAGED TASK doit être accordé au rôle de propriétaire.

Ces modifications ont pour but de vous aider à mieux comprendre et à résoudre les problèmes liés aux tâches sans serveur.

Changements dans la confidentialité des données

Classification : mises à jour du modèle de classification des données et résultat vérifié

La classification des données est maintenant disponible de façon générale (GA) dans tous les comptes Enterprise Edition (ou plus) sur AWS et Azure.

Pour la GA de la fonctionnalité, le modèle de classification des données a été mis à jour afin de générer un modèle de prédiction et des résultats de modèle de données améliorés. En outre, le processus de classification de données inclut désormais des résultats pour chaque colonne de table spécifiée en entrée, notamment :

  • Des colonnes dont les types de données ne pouvaient pas être classés auparavant.

  • Des colonnes comportant uniquement des valeurs NULL.

Ces améliorations ont été introduites par le biais du processus de changement de comportement parce qu’elles offrent probablement de meilleurs résultats, mais potentiellement différents, lors de la re-classification des données qui ont été classées à l’aide du modèle de classification des données précédent. Au cours de la phase de fin d’abonnement pour le bundle 2022_04, vous pouvez activer/désactiver le bundle pour tester les améliorations de classification tout en réduisant leur impact sur vos comptes de production jusqu’à ce que vous soyez familiarisé avec les nouveaux résultats.