Bundle 2022_04¶

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.

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 :

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

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 :

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

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.

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.