Bundle 2022_06

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 Septembre 2022.

Important

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

Dans ce chapitre :

Changements SQL — Général

Groupes de réplication : types d’objets limités aux bases de données et aux partages pour les comptes qui ne sont pas de la Business Critical Edition

La fonction de réplication de compte prend en charge la réplication des objets de compte, notamment les utilisateurs, les rôles, les bases de données et les partages. Pour la liste complète des types d’objets pris en charge, voir Objets répliqués. Les groupes de réplication peuvent inclure tout ou partie des types d’objets pris en charge.

Le comportement a changé comme suit :

Précédemment:

Tous les types d’objets de réplication de compte pris en charge peuvent être inclus dans un groupe de réplication.

Actuellement:

La prise en charge des types d’objets pouvant être ajoutés à un groupe de réplication pour les comptes qui ne sont pas Business Critical Edition (ou supérieur) est limitée aux bases de données et aux partages.

Consultez le tableau de prise en charge des fonctionnalités de réplication de compte pour plus de détails sur la prise en charge des fonctionnalités par édition.

Stockage Fail-safe : correction d’un bogue pour les cas particuliers entraînant une sous-facturation

En raison d’une erreur interne du système, certaines tables permanentes n’ont pas été facturées pour le stockage d’octets Fail-safe. Plus précisément, si une table temporaire est créée en tant que clone d’une table permanente, et que la table permanente est ensuite détruite, Snowflake n’a pas facturé le stockage Fail-safe de la table permanente.

La facturation de Fail-safe a changé comme suit :

Précédemment:

Certaines tables permanentes n’ont pas été facturées pour le stockage Fail-safe.

Actuellement:

Les clients sont facturés pour le stockage Fail-safe de toutes les tables permanentes.

Changements SQL — Commandes et fonctions

Commandes CREATE DATABASE et CREATE SCHEMA : une clause OR REPLACE entraîne des références pendantes pour les politiques

Le comportement des commandes CREATE DATABASE et CREATE SCHEMA a changé comme suit :

Précédemment:

Snowflake a permis aux commandes CREATE OR REPLACE DATABASE et CREATE OR REPLACE SCHEMA de s’exécuter sur la base de données ou le schéma contenant une politique de masquage ou une politique d’accès aux lignes qui protègent un objet dans une base de données ou un schéma différent. Par exemple :

  • Une politique de masquage nommée db1.s1.p1 protège une colonne nommée db2.s1.t1.c1.

  • Une politique d’accès aux lignes nommée db1.s1.p2 protège une table nommée db2.s1.t1.

Le résultat était une référence pendante qui faisait échouer toutes les requêtes sur la colonne ou l’objet.

Notez que ce comportement s’applique également aux instructions CLONE telles que CREATE OR REPLACE SCHEMA S1 CLONE S2;.

Actuellement:

La commande CREATE OR REPLACE DATABASE ou CREATE OR REPLACE SCHEMA échoue si le résultat est une référence pendante sur un objet protégé par une politique. Snowflake renvoie l’un des messages d’erreur suivants :

  • Pour CREATE OR REPLACE DATABASE : Cannot drop database because: Policy '<db.schema.policy>' used by schema '<db.schema>' in another database

  • Pour CREATE OR REPLACE SCHEMA : Cannot drop schema because: Policy '<db.schema.policy>' used by another schema '<db.schema>'

Si l’un des deux messages d’erreur apparaît, interrogez la vue Account Usage POLICY_REFERENCES, utilisez un rôle pour désactiver la politique de masquage ou d’accès aux lignes, puis réessayez l’instruction CREATE OR REPLACE.

Par exemple :

  1. Interrogez la vue :

    • Références de politique inter-schémas qui doivent être supprimées avant le remplacement :

      select * from snowflake.account_usage.policy_references
      where policy_db=<policy_db> and
      policy_schema=<policy_schema_to_replace> and ref_schema_name != <policy_schema>;
      
      Copy
    • Références de politique inter-base de données qui doivent être supprimées avant le remplacement :

      select * from snowflake.account_usage.policy_references
      where policy_db=<policy_db_to_replace>’ and ref_database_name != <policy_db>;
      
      Copy
  2. Désactiver les politiques :

    • Pour les politiques de masquage :

      alter table <table_name> modify column <col_name> unset masking policy;
      
      Copy
    • Pour les politiques d’accès aux lignes :

      alter table <table_name> drop all row access policies;
      
      Copy
  3. Réessayer la commande CREATE OR REPLACE.

Notez que, avec les opérations CLONE, vous devez stocker les objets de politique dans une base de données ou un schéma distinct avant d’exécuter les instructions CLONE.

Fonction INFER_SCHEMA : nouvelle colonne ORDER_ID dans la sortie

La sortie de la fonction INFER_SCHEMA comprend maintenant une nouvelle colonne ORDER_ID qui indique l’ordre des colonnes dans les fichiers en zone de préparation.

Actuellement, lorsque vous créez une table avec les définitions de colonnes dérivées d’un ensemble de fichiers en zone de préparation (en utilisant CREATE TABLE … USING TEMPLATE), l’ordre des colonnes dans la table est aléatoire. Bien que l’ordre des colonnes de la table n’ait pas d’importance pour Snowflake, cela peut être source de confusion lorsque vous comparez l’ordre des colonnes du fichier à celui de la table. La nouvelle colonne ORDER_ID dans la sortie INFER_SCHEMA peut vous aider à vous assurer que les tables créées avec le schéma détecté ont le même ordre des colonnes.

Vous pouvez récupérer le schéma de n’importe quel fichier en utilisant INFER_SCHEMA, comme le montre l’exemple suivant. La sortie inclut une nouvelle colonne ORDER_ID et est triée par ORDER_ID automatiquement pour le scénario à schéma unique :

SELECT *
  FROM TABLE(
  INFER_SCHEMA(
  LOCATION=>'@***_****_STAGE/' , FILE_FORMAT=>'FFPARQUET'
  )
  );
Copy

De même, vous pouvez créer une table en utilisant le schéma détecté à partir de fichiers en zone de préparation et trier les colonnes par ORDER_ID, comme le montre l’exemple suivant :

CREATE OR REPLACE TABLE BIG_TABLE
  USING TEMPLATE (
  SELECT ARRAY_AGG(OBJECT_CONSTRUCT(*))
  WITHIN GROUP (ORDER BY ORDER_ID) // NEW
  FROM TABLE( INFER_SCHEMA(LOCATION=>'@***_****_STAGE/', FILE_FORMAT=>'FFPARQUET')
  )
  );

DESC TABLE BIG_TABLE;
Copy

Notez que le tri des colonnes par ORDER_ID ne s’applique que si tous les fichiers en zone de préparation partagent un même schéma. Si l’ensemble des fichiers de données mis à disposition comprend plusieurs schémas avec des noms de colonnes partagés, l’ordre représenté dans la colonne ORDER_ID peut ne pas correspondre à un seul fichier.

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

FUNCTIONS Vue (Account Usage) : nouvelles colonnes dans vue

La sortie de la vue Account Usage FUNCTIONS comprend maintenant les nouvelles colonnes suivantes :

Nom de la colonne

Type de données

Description

PACKAGES

STRING

Spécifie les packages demandés par la fonction.

RUNTIME_VERSION

STRING

Spécifie la version d’exécution de la fonction. NULL si la fonction est SQL ou Javascript.

INSTALLED_PACKAGES

STRING

Liste tous les packages installés par la fonction. Sortie pour les fonctions Python uniquement.