Bundle 2022_07¶

Bases de données et schémas : l’élimination ou le remplacement ne sont pas autorisés s’il en résulte des références ambiguës pour les politiques et les balises.¶

Le comportement des opérations de suppression ou de remplacement d’une base de données/un schéma en ce qui concerne une politique de masquage, une balise et une colonne protégée dans une table a été modifié comme suit :

Précédemment:

Lorsque la balise et la politique sont dans le même schéma et que la table est dans un schéma différent, Snowflake a autorisé les opérations DROP et REPLACE sur le schéma/base de données qui contient une balise et une politique de masquage lorsque la colonne protégée dans la table existe dans un schéma/une base de données différent(e).

Ce comportement s’appliquait aux quatre commandes suivantes :

• DROP DATABASE

• DROP SCHEMA

• CREATE OR REPLACE DATABASE

• CREATE OR REPLACE SCHEMA

Actuellement:

Si le même scénario se produit maintenant, Snowflake n’autorise pas les opérations DROP et REPLACE sur le schéma/base de données qui contient une balise et une politique de masquage lorsque la colonne protégée de la table existe dans un schéma/une base de données différent(e).

En conséquence, le comportement des quatre commandes énumérées ci-dessus a changé.

Par exemple :

• Une balise nommée t1 et une politique de masquage nommée p1 existent dans le schéma nommé governance.tags.

• La politique de masquage p1 est attribuée à la balise t1 (c’est-à-dire une politique de masquage basée sur la balise).

• La balise t1 est affectée à une table nommée finance.accounting.customers.

Auparavant, Snowflake autorisait l’opération DROP SCHEMA sur le schéma governance.tags et l’opération DROP DATABASE sur la base de données governance alors que la balise t1 était affectée à la table finance.accounting.customers.

Or, Snowflake ne permet pas d’effectuer l’une ou l’autre de ces opérations tant que la balise t1 est attribuée à la table. Selon l’opération tentée, Snowflake renvoie l’un des messages d’erreur suivants :

• DROP DATABASE et CREATE OR REPLACE DATABASE :

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

• DROP SCHEMA et CREATE OR REPLACE SCHEMA :

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

Commande CREATE MATERIALIZED VIEW : les clauses Time Travel ne sont plus autorisées¶

Les vues matérialisées n’autorisent pas la prise en charge de Time Travel. Cependant, lorsque vous exécutez la commande CREATE MATERIALIZED VIEW, il était possible de spécifier une clause Time Travel (par exemple, AT) pour la table de base de la vue.

La spécification d’une clause Time Travel dans CREATE MATERIALIZED VIEW entraîne désormais une erreur.

Précédemment:

La spécification d’une clause Time Travel dans CREATE MATERIALIZED VIEW n’a pas produit d’erreur.

Par exemple, les instructions suivantes se sont exécutées avec succès, sans aucune erreur :

• Exemple 1 :

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

  Copy

• Exemple 2 :

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

  Copy

• Exemple 3 :

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

  Copy

Actuellement:

La spécification d’une clause Time Travel dans CREATE MATERIALIZED VIEW produit maintenant l’erreur suivante :

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

Vue GRANT_TO_ROLES (Account Usage) : modifications de la vue¶

Les modifications suivantes ont été apportées à la vue ACCOUNT_USAGE.GRANTS_TO_ROLES.

Précédemment:

La sortie de la vue incluait les octrois de privilèges aux rôles sur les tables temporaires.

Actuellement:

La sortie de la vue n’inclut pas les octrois de privilèges aux rôles sur les tables temporaires.

Commande CREATE EXTERNAL TABLE : partitions spécifiées par l’utilisateur et métadonnées actualisées automatiquement¶

Définir les partitions d’une table externe comme étant spécifiées par l’utilisateur signifie que vous choisissez d’ajouter et de supprimer des partitions de manière sélective plutôt que d’ajouter automatiquement des partitions pour tous les nouveaux fichiers dans un emplacement de stockage externe et qui correspondent à une expression. Ce type de partition est spécifié en incluant le paramètre PARTITION_TYPE = USER_SPECIFIED lorsque vous créez une table externe. Le partitionnement spécifié par l’utilisateur ne prend pas en charge l’actualisation automatique des métadonnées de table externes.

Lorsqu’une instruction CREATE EXTERNAL TABLE est exécutée avec les paramètres PARTITION_TYPE = USER_SPECIFIED et AUTO_REFRESH = TRUE définis, le comportement a changé comme suit :

Précédemment:

L’instruction CREATE EXTERNAL TABLE s’est déroulée avec succès ; toutefois, toute notification d’événement reçue du stockage Cloud pour la table externe (par exemple, les messages « nouvel objet ») a produit une erreur.

Actuellement:

L’instruction CREATE EXTERNAL TABLE renvoie une erreur d’utilisateur.

Fonction GET_DDL : retourne le paramètre TABLE_FORMAT pour les tables externes sur le Delta Lake¶

Lorsque l’entrée de la fonction GET_DDL est une table externe qui fait référence à une table Delta Lake, l’instruction CREATE EXTERNAL TABLE renvoyée par la fonction a été modifiée comme suit :

Précédemment:

L’instruction omettait le paramètre TABLE_FORMAT = DELTA qui identifie la table externe comme faisant référence à une table Delta Lake.

Actuellement:

L’instruction inclut le paramètre TABLE_FORMAT = DELTA.

Snowpark pour Python : retourne les erreurs plus tôt lors de l’ajout de paquets non valides¶

Lors de l’ajout d’un paquet Python à une session Python Snowpark, l’utilisateur reçoit un message d’erreur si le paquet ou sa version spécifiée n’est pas pris en charge par Snowflake.

L’heure à laquelle le message d’erreur est reçu a été modifiée pour être plus précoce :

Précédemment:

L’erreur a été reçue uniquement lorsque l’utilisateur a essayé d’enregistrer une UDF ou une procédure stockée.

Actuellement:

L’erreur se produit plus tôt, lorsque add_packages est utilisé pour ajouter le paquet Python.

Par exemple, l’appel de "session.add_packages('numpy==21.21.21')" donne "ValueError" car la version du paquet n’est pas valide.

Snowpark pour Scala et Java : modification des types de membres dans DeleteResult, MergeResult, et UpdateResult¶

Dans les APIs Snowpark Scala et Java, les classes DeleteResult, MergeResult et UpdateResult fournissent des membres de valeur et des méthodes getter qui renvoient le nombre de lignes qui ont été insérées, mises à jour et supprimées :

• Dans l’API Snowpark Scala, ces membres de valeur sont nommés :

  • rowsInserted

  • multiJoinedRowsUpdated

  • rowsUpdated

  • rowsDeleted

• Dans l’API Snowpark Java, ces méthodes getter sont nommées :

  • getRowsInserted

  • getMultiJoinedRowsUpdated

  • getRowsUpdated

  • getRowsDeleted

Dans la version 1.7.0 de la bibliothèque Snowpark pour Scala et Java, les types de ces membres de valeur et les types de retour de ces méthodes getter ont changé :

Avant la version 1.7.0:

• Dans l’API Scala, le type est Int.

• Dans l’API Java, le type est int.

À partir de la 1.7.0:

• Dans l’API Scala, le type est Long.

• Dans l’API Java, le type est long.