Bundle 2022_07¶
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 Octobre 2022.
Important
Sauf indication contraire, ces modifications sont présentes dans le bundle 2022_07, qui a été activé par défaut dans la version 6.35.
Dans ce chapitre :
Changements SQL — Commandes et fonctions¶
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 :
- 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éep1
existent dans le schéma nommégovernance.tags
.La politique de masquage
p1
est attribuée à la baliset1
(c’est-à-dire une politique de masquage basée sur la balise).La balise
t1
est affectée à une table nomméefinance.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);
Exemple 2 :
create or replace materialized view mv as select * from basetbl at(timestamp => $ts);
Exemple 3 :
create or replace materialized view mv as select * from basetbl at(statement => $uuid_dml);
- 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.
Changements SQL — Vues d’utilisation et vues Information Schema/Fonctions de table¶
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.
Changements au niveau du data lake¶
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
.
Modifications de l’extensibilité¶
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
.