Décembre 2022¶
Les nouvelles fonctionnalités, les changements de comportement et les mises à jour (améliorations, corrections, etc.) suivants ont été introduits ce mois-ci. Si vous avez des questions sur ces ajouts, veuillez contacter le support Snowflake.
Important
Chaque version peut inclure des mises à jour nécessitant l’actualisation de l’interface Web.
En règle générale, pour éviter que ces mises à jour nuisent à votre utilisation, nous vous recommandons d’actualiser l’interface Web après le déploiement de chaque version de Snowflake.
Dans ce chapitre :
Nouvelles fonctionnalités¶
Contrôle d’accès : rôles de bases de données — Avant-première¶
Avec cette version, nous avons le plaisir d’annoncer la prise en charge en avant-première des rôles de bases de données. Les rôles de bases de données sont des entités au sein d’une base de données auxquelles des privilèges sur des objets sécurisés de la même base de données peuvent être accordés et révoqués. Cette fonctionnalité est mise en œuvre via un nouveau type d’objet Snowflake, le rôle de base de données. Les rôles de base de données sont essentiellement les mêmes que les rôles traditionnels créés au niveau du compte, à l’exception de leur portée. Les privilèges sur tous les objets d’un compte peuvent être accordés aux rôles de compte, mais seuls les privilèges sur les objets de la même base de données peuvent être accordés à un rôle de base de données.
Les rôles de base de données sont destinés à satisfaire les cas d’utilisation suivants :
Facilité de gestion |
Les propriétaires de bases de données peuvent gérer de manière indépendante l’accès aux objets sécurisables au sein de leurs propres bases de données. Les propriétaires de la base de données peuvent effectuer les actions suivantes :
Notez que l’octroi d’un rôle de base de données à un rôle de compte accorde implicitement le privilège USAGE sur la base de données qui contient le rôle de base de données. Il n’est pas nécessaire d’accorder explicitement le privilège USAGE sur la base de données. |
|---|---|
Partage de données |
Les fournisseurs de données utilisant la fonction Secure Data Sharing de Snowflake peuvent segmenter les objets sécurisables dans un partage en créant plusieurs rôles de base de données dans une base de données à partager et en accordant des privilèges sur un sous-ensemble d’objets de la base de données à chaque rôle de base de données. Après avoir créé une base de données à partir d’un partage qui inclut des rôles de base de données, les consommateurs de données accordent chaque rôle de base de données partagée à un ou plusieurs rôles de niveau compte dans leur propre compte. Sans les rôles de base de données, les administrateurs de comptes de consommateurs de données accordent un privilège unique, IMPORTED PRIVILEGES, aux rôles pour permettre à leurs utilisateurs d’accéder à toutes les bases de données et à tous les objets de base de données (tables, vues sécurisées, etc.) d’un partage. Il n’y a pas d’option pour permettre à différents groupes d’utilisateurs dans un compte de consommateur de données d’accéder à un sous-ensemble d’objets partagés. Cette approche du tout ou rien oblige les fournisseurs de données à créer plusieurs partages pour accorder l’accès à différents objets dans les mêmes bases de données. Note Actuellement, les rôles de bases de données ne sont pas inclus dans la réplication d’une base de données principale. Par conséquent, le partage de données inter-régional n’est pas pris en charge lorsque des objets sont accordés à un partage via des rôles de base de données. |
Pour plus de détails, reportez-vous aux rôles de bases de données.
Contrôle d’accès : rôles de bases de données SNOWFLAKE — Avant-première¶
Avec cette version, nous avons le plaisir d’annoncer la prise en charge en avant-première des rôles de bases de données SNOWFLAKE. Les rôles de base de données SNOWFLAKE mettent en œuvre le concept des rôles généraux de base de données, mais spécifiquement pour la base de données SNOWFLAKE. Les rôles de base de données SNOWFLAKE définissent un ensemble de rôles qui peuvent être utilisés pour fournir un accès précis au schéma ACCOUNT_USAGE, au schéma READER_ACCOUNT_USAGE, au schéma ORGANIZATION_USAGE, au schéma DATA_SHARING_USAGE, etc.
Les rôles de base de données SNOWFLAKE seront déployés sur tous les comptes au cours de la semaine du 12 décembre 2022. Pour plus d’informations, reportez-vous à Rôles des bases de données SNOWFLAKE.
Extension Snowflake pour Visual Studio Code — Avant-première¶
Avec cette version, nous avons le plaisir d’annoncer l’avant-première de l”Snowflake Extension for Visual Studio Code (VS Code). L”Snowflake Extension for Visual Studio Code permet aux développeurs d’accéder à Snowflake à partir de l’environnement VS Code. L’extension vous permet de vous connecter à Snowflake, d’écrire et d’exécuter des requêtes SQL, et de visualiser les résultats sans quitter VS Code. Après vous être connecté, vous pouvez voir et modifier votre base de données, votre schéma, votre rôle et votre entrepôt actifs.
Snowflake Intellisence offre une prise en charge de la saisie semi-automatique pour les noms des objets de base de données, les fonctions intégrées et les mots-clés SQL Snowflake. Grâce à Intellisense, les suggestions de nom de base de données, de schéma et de table s’affichent pendant que vous tapez votre requête. Des requêtes uniques ou des groupes de requêtes peuvent être exécutés, avec des résultats fournis directement dans VS Code.
Pour plus d’informations, reportez-vous à Snowflake Extension for Visual Studio Code.
Mises à jour de sécurité¶
Politiques de session — Disponible de manière générale¶
Avec cette version, Snowflake est heureux d’annoncer la disponibilité générale des politiques de session. Une politique de session définit le délai d’expiration d’une session inactive en minutes et permet de remplacer la valeur par défaut du délai d’expiration d’une session inactive de 4 heures. Le délai d’expiration d’une session inactive fait référence à une période d’inactivité soit avec l’interface Web de Snowflake, soit avec des applications clientes utilisant des clients Snowflake (par exemple SnowSQL, le pilote JDBC). Lorsque le délai d’expiration d’une session inactive expire, les utilisateurs doivent se réauthentifier auprès de Snowflake.
La politique de session peut être définie pour un compte ou un utilisateur et prend en charge des délais d’expiration en cas d’inactivité configurables pour répondre à des exigences de conformité. Si un utilisateur est associé à la fois à une politique de session de compte et de niveau utilisateur, la politique de session de niveau utilisateur a la priorité.
Cette fonctionnalité a été annoncée en avant-première en novembre 2021 . Pour plus d’informations, reportez-vous à Sessions Snowflake et politiques de session.
Mises à jour SQL¶
Nouvelles fonctions SQL¶
La ou les fonctions suivantes ont été introduites dans des versions récentes :
Catégorie de fonction |
Nouvelle fonction |
Description |
|---|---|---|
Fonctions système (requête), fonctions de table |
Renvoie des statistiques sur les opérateurs de requête individuels dans une requête. |
Commande ALTER TAG : ajouter le mot-clé FORCE pour remplacer une politique de masquage sur une balise dans une seule instruction¶
Syntaxe |
Mot clé |
Description |
|---|---|---|
ALTER TAG <nom> SET MASKING POLICY <nom_politique_masquage> [ FORCE ] |
FORCE |
Remplace une politique de masquage actuellement définie sur une balise par une politique de masquage différente dans une seule instruction. Notez que l’utilisation du mot-clé FORCE remplace la politique lorsqu’une politique du même type de données est déjà définie sur la balise. Si aucune politique de masquage n’est actuellement définie sur la balise, la spécification de ce mot-clé n’a aucun effet. |
Mises à jour de la gouvernance des données¶
Remplacer une politique de masquage sur une balise dans une seule instruction¶
Avec cette version, Snowflake ajoute la possibilité de spécifier le mot-clé FORCE lors du remplacement d’une politique de masquage actuellement définie sur une balise dans une seule instruction avec une commande ALTER TAG. Avant la disponibilité du mot-clé FORCE le remplacement d’une politique de masquage sur une balise nécessitait deux instructions distinctes :
Annuler la politique existante.
Définir la nouvelle politique.
L’utilisation du mot-clé FORCE supprime l’intervalle de temps entre les opérations UNSET et SET afin de garantir que les données de la colonne restent protégées lors du remplacement d’une politique de masquage sur une balise.
Pour plus de détails, reportez-vous à :
Commande ALTER TAG : ajouter le mot-clé FORCE pour remplacer une politique de masquage sur une balise dans une seule instruction (dans cette rubrique)
Remplacer une politique de masquage sur une balise (dans la documentation Snowflake)
Documentation et matériel d’apprentissage¶
Mises à jour de la table des matières (TOC)¶
Pour permettre aux développeurs de trouver plus facilement du contenu, nous avons introduit les changements suivants à la TOC :
Entrée de niveau supérieur |
Entrée de deuxième niveau |
Entrée de troisième niveau |
Changement |
|---|---|---|---|
Développement d’applications avec Snowflake |
Introduction au développement d’applications dans Snowflake |
Supprimé. |
|
Aperçu des connecteurs, des pilotes et des APIs client |
Supprimé. |
||
UDFs |
Déplacé dans : Développement d’applications et d’extensions » Extension de Snowflake avec des fonctions et des procédures |
||
Snowpark |
Déplacé dans : API Snowpark |
||
Fonctions externes |
Déplacé dans : Développement d’applications et d’extensions » Extension de Snowflake avec des fonctions et des procédures |
||
Procédures stockées |
Déplacé dans : Développement d’applications et d’extensions » Extension de Snowflake avec des fonctions et des procédures |
||
Protection des informations sensibles avec les UDFs et les procédures stockées sécurisées |
Déplacé dans : Développement d’applications et d’extensions » Extension de Snowflake avec des fonctions et des procédures » Directives et contraintes de conception pour les fonctions et les procédures |
||
Optimisation du pushdown et visibilité des données |
Déplacé dans : Développement d’applications et d’extensions » Extension de Snowflake avec des fonctions et des procédures » Directives et contraintes de conception pour les fonctions et les procédures |
||
Exécution de scripts Snowflake |
Déplacé dans : Guide du développeur Exécution de scripts Snowflake |
||
Connexion à Snowflake |
Connecteurs et pilotes |
Connecteur Snowflake pour Kafka |
Déplacé dans : Développement d’applications et d’extensions » Utilisation de Snowflake avec Kafka et Spark |
Connecteur Snowflake pour Spark |
Déplacé dans : Développement d’applications et d’extensions » Utilisation de Snowflake avec Kafka et Spark |
||
Connecteur Snowflake pour Python |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
Pilote Node.js |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
Pilote Go Snowflake |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
Pilote .NET |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
Pilote JDBC |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
Pilote ODBC |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
Pilote PHP PDO de Snowflake |
Déplacé dans : Développement d’applications et d’extensions » Pilotes |
||
API SQL Snowflake |
Déplacé dans : API REST SQL Snowflake |