Bundle 2021_10

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 Février 2022.

Important

Sauf indication contraire, ces modifications sont présentes dans le bundle 2021_10, qui a été activé par défaut dans la version 6.2.

Dans ce chapitre :

Changements en matière de sécurité

Commande DESCRIBE USER : nouvelles colonnes RSA_PUBLIC_KEY et RSA_PUBLIC_KEY_2 dans la sortie

La sortie de la commande DESCRIBE USER comprend deux nouvelles colonnes :

  • RSA_PUBLIC_KEY

  • RSA_PUBLIC_KEY_2

Ces deux colonnes facilitent l’obtention de clés publiques qui sont actuellement définies pour l’utilisateur.

Changements SQL — Général

Contraintes : modifications apportées aux vues et à la propriété de contrainte RELY

Le comportement de la propriété de contrainte RELY, et des deux vues pour les contraintes (Vue TABLE_CONSTRAINTS dans ACCOUNT_USAGE et Vue TABLE_CONSTRAINTS dans INFORMATION_SCHEMA) a changé comme suit :

Précédemment

Lorsque vous créiez une nouvelle contrainte :

  • RELY était la valeur par défaut.

  • Vous ne pouviez pas contourner ceci en spécifiant NORELY dans la commande. Si vous aviez spécifié NORELY dans la commande, NORELY était ignoré ou une erreur était générée.

Pour les contraintes existantes, vous ne pouviez pas modifier la propriété de contrainte RELY.

Les vues suivantes ne fournissaient pas d’informations sur la propriété de contrainte RELY :

  • TABLE_CONSTRAINTS dans ACCOUNT_USAGE.

  • TABLE_CONSTRAINTS dans INFORMATION_SCHEMA.

Actuellement

Lorsque vous créez une nouvelle contrainte :

  • NORELY est défini par défaut.

  • Vous pouvez contourner ceci en spécifiant RELY dans la commande.

Toutes les contraintes existantes ont la propriété NORELY (que la contrainte ait ou non la propriété RELY ou NORELY). Vous pouvez modifier la propriété de contrainte en passant de NORELY à RELY.

Les vues suivantes incluent une colonne RELY qui spécifie si la propriété de contrainte RELY est définie ou non :

  • TABLE_CONSTRAINTS dans INFORMATION_SCHEMA. (Mise à jour : la colonne RELY a été ajoutée en août 2022).

La colonne RELY sera ajoutée à TABLE_CONSTRAINTS dans ACCOUNT_USAGE dans une prochaine version.

Cette modification a été apportée pour prendre en charge les améliorations à venir en matière d’optimisation des requêtes. Ces améliorations font appel aux contraintes définies pour la table.

Avec le nouveau paramètre NORELY par défaut, l’optimiseur de requêtes ne suppose pas que les données d’une table sont conformes aux contraintes. Si vous avez la certitude que les données de la table respectent les contraintes, vous pouvez remplacer cette valeur par RELY (pour indiquer que l’optimiseur de requêtes doit s’attendre à ce que les données de la table respectent les contraintes).

Vues matérialisées : modification de la façon dont les vues sont créées lors du clonage des bases de données

La façon dont les vues matérialisées sont créées lorsque vous clonez une base de données a changé comme suit :

Précédemment

Lorsque vous clonez une base de données, toutes les vues matérialisées de la base de données clonée étaient créées avec des noms entièrement qualifiés, même si vous n’aviez pas spécifié le nom entièrement qualifié lors de la création de la vue dans la base de données d’origine.

Par exemple, supposons que vous avez créé une vue matérialisée avec le nom non qualifié mv dans une base de données db1 :

use database db1;
create materialized view mv as ...;
Copy

Supposons que vous clonez ensuite la base de données db1 :

create database db1_clone clone db1;
Copy

L’instruction CREATE MATERIALIZED VIEW qui a créé la vue dans la base de données clonée a utilisé le nom entièrement qualifié de la vue.

Vous pouvez visualiser cette instruction en exécutant la commande SHOW MATERIALIZED VIEWS :

use database db1_clone;
show materialized views;
Copy

La colonne nommée texte contient le texte de la commande qui a créé cette vue matérialisée :

| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...
Copy

Comme le montre cet exemple, la commande a utilisé le nom entièrement qualifié de la vue matérialisée (DB1_CLONE.PUBLIC.MV).

Actuellement

L’instruction CREATE MATERIALIZED VIEW de la base de données clonée n’inclut pas le nom de la base de données clonée et du schéma sauf si ces noms ont été spécifiés dans l’instruction CREATE MATERIALIZED VIEW d’origine.

Par exemple, supposons que vous créez une vue matérialisée avec le nom non qualifié mv dans une base de données db1 :

use database db1;
create materialized view mv as ...;
Copy

Supposons que vous clonez ensuite la base de données db1 :

create database db1_clone clone db1;
Copy

Lorsque vous exécutez la commande :

use database db1_clone;
show materialized views;

-- OR --

use database db1_clone;
show views;
Copy

L’instruction CREATE MATERIALIZED VIEW dans la colonne de texte utilise le nom non qualifié de la vue parce que ce nom non qualifié a été utilisé dans l’instruction CREATE MATERIALIZED VIEW d’origine :

| text
+------ ...
| create or replace materialized view mv as ...
Copy

Cette modification a été apportée pour éviter d’éventuels problèmes lors du renommage d’une base de données clonée. Lorsque vous renommez une base de données clonée, le nom d’origine de la base de données clonée n’est pas mis à jour dans la vue matérialisée.

Par exemple, supposons que vous renommiez la base de données clonée db1_clone en db2 :

alter database db1_clone rename to db2;
Copy

Lorsque vous exécutez la commande suivante :

use database db2;
show materialized views;
Copy

La commande dans la colonne de texte a utilisé le nom d’origine de la base de données clonée (db1_clone) et non le nouveau nom de la base de données clonée (db2) :

| text
+------ ...
| create or replace materialized view DB1_CLONE.PUBLIC.MV as ...
Copy

Par conséquent, l’interrogation de la vue matérialisée entraîne une erreur :

select * from mv;

SQL compilation error: Failure during expansion of view 'MV': Cannot perform SELECT.
Copy

Ce changement de comportement empêche cette erreur de se produire.

Changements SQL — Commandes et fonctions

Commande SHOW ORGANIZATION ACCOUNTS : nouvelles colonnes dans la sortie

Pour permettre une meilleure compréhension des mappages des comptes aux entités de facturation dans une organisation, les colonnes suivantes ont été ajoutées dans la sortie de la commande SHOW ORGANIZATION ACCOUNTS :

Nom de la colonne

Type de données

Description

CONSUMPTION_BILLING_ENTITY_NAME

TEXT

Le nom de l’entité de facturation de consommation.

MARKETPLACE_CONSUMER_BILLING_ENTITY_NAME

TEXT

Le nom de l’entité de facturation du consommateur de la place de marché.

MARKETPLACE_PROVIDER_BILLING_ENTITY_NAME

TEXT

Le nom de l’entité de facturation du fournisseur de la place de marché.

Fonction GET_DDL : modifications des vues

La fonction GET_DDL renvoie une instruction DDL qui peut être utilisée pour recréer l’objet spécifié, avec des variations dans la sortie de la requête en fonction de l’objet spécifié dans l’argument de la fonction. Le comportement de la fonction GET_DDL pour les vues a été modifié comme suit :

Précédemment

Snowflake a renvoyé l’instruction SQL exacte pour recréer la vue. Si la vue était une vue sécurisée, Snowflake renvoyait l’instruction DDL pour créer la vue et une instruction ALTER pour définir la propriété SECURE sur la vue.

Actuellement

Snowflake a mis à jour le résultat de la requête pour les vues comme suit :

  • Le résultat de la requête renvoie le texte SQL en minuscules pour create or replace view, même si la casse dans l’instruction SQL d’origine utilisée pour créer la vue était en majuscules ou mixte.

  • La clause OR REPLACE est toujours incluse dans l’instruction CREATE VIEW.

  • Les commentaires SQL précédant le corps de la vue (AS) sont supprimés.

  • La liste des colonnes est toujours générée. Si une politique de masquage est définie sur une colonne, le résultat spécifie la politique de masquage pour la colonne.

  • Si la vue possède une politique de masquage sur une ou plusieurs de ses colonnes ou une politique d’accès aux lignes et que le rôle qui exécute la requête GET_DDL ne possède pas le privilège global APPLY MASKING POLICY ou APPLY ROW ACCESS POLICY, le nom de la politique est remplacé par #unknown_policy. Voir la remarque ci-dessous.

  • Si la vue est sécurisée, le résultat de la requête inclut la propriété SECURE dans l’instruction CREATE ; une instruction ALTER supplémentaire pour définir la propriété SECURE n’est plus incluse dans le résultat de la requête.

  • L’instruction COPY GRANTS n’est pas incluse, même si elle était spécifiée dans l’instruction CREATE VIEW d’origine.

  • Assure que l’instruction CREATE VIEW comprend toujours un point-virgule à la fin.

Note

  • Pour une vue qui inclut une politique de masquage, une politique d’accès aux lignes ou les deux, le résultat de la requête en attente avec le texte #unknown_policy fait échouer l’instruction CREATE VIEW si ce texte n’est pas supprimé avant de recréer la vue. Ce comportement est attendu. L’utilisation de ce texte a pour but d’indiquer que la colonne ou la vue est protégée par une politique.

  • Si le résultat de la requête GET_DDL comprend le texte #unknown_policy , avant de recréer la vue, consultez votre administrateur de gouvernance interne pour déterminer les politiques nécessaires pour les colonnes ou la vue, modifiez le résultat de la requête GET_DDL, puis recréez la vue.

Fonction INFER_SCHEMA : remplacement par des colonnes NULL

La fonction INFER_SCHEMA détecte les définitions de colonnes dans un ensemble de fichiers de données en zone de préparation qui contient des données semi-structurées et récupère les métadonnées dans un format adapté à la création d’objets Snowflake.

La condition qui détermine si la fonction renvoie la contrainte NULL ou NOT NULL pour une colonne a été modifiée comme suit :

Précédemment

La fonction INFER_SCHEMA renvoyait la contrainte de nullité pour une colonne, comme indiqué dans les métadonnées des fichiers qui incluent la colonne. Lorsque l’entrée de la fonction était un fichier unique, la contrainte de nullité renvoyée pour les colonnes était toujours correcte. Cependant, lorsqu’une colonne était identifiée dans les métadonnées comme étant nécessaire, mais qu’elle ne figurait pas dans tous les fichiers d’entrée, la fonction renvoyait toujours une contrainte NOT NULL pour cette colonne. Cette logique pouvait entraîner des erreurs lors du chargement de tous les fichiers dans une table créée en utilisant la sortie de la fonction INFER_SCHEMA.

Lors de la création d’une table dont les définitions de colonnes étaient dérivées d’un ensemble de fichiers de données en zone de préparation (à l’aide de la syntaxe CREATE TABLE … USING TEMPLATE), toutes les colonnes de la table étaient définies comme Null.

Actuellement

La fonction INFER_SCHEMA renvoie une colonne comme Null si la colonne est manquante ou indiquée comme facultative dans les fichiers d’entrée. La fonction renvoie une colonne comme non Null uniquement si la colonne est identifiée comme requise dans tous les fichiers d’entrée.

La fonction GENERATE_COLUMN_DESCRIPTION et la syntaxe de la commande CREATE TABLE … USING TEMPLATE suivent le même comportement de nullité que la fonction INFER_SCHEMA.

Changements SQL — Vues d’utilisation et Information Schema

Vue ACCESS_HISTORY : prise en charge des opérations d’écriture

Le comportement de Vue ACCESS_HISTORY dans le schéma ACCOUNT_USAGE a été modifié comme suit :

Précédemment

La vue ACCESS_HISTORY ne prenait en charge que les opérations de lecture SQL.

Actuellement

La vue ACCESS_HISTORY prend en charge les opérations de lecture et d’écriture SQL comme suit :

  • Des lignes supplémentaires ont été incluses dans la sortie de la requête de la vue pour indiquer que des opérations d’écriture ont eu lieu.

  • Une nouvelle colonne, OBJECTS_MODIFIED, de type de données ARRAY, spécifie les objets qui ont été modifiés dans la partie écriture d’une requête SQL.

  • S’il y a eu un accès à la zone de préparation, le champ objectDomain indique la valeur STAGE.

  • S’il y a eu un accès à la zone de préparation dans la partie lecture de la requête, les colonnes DIRECT_OBJECTS_ACCESSED et BASE_OBJECTS_ACCESSED ont été mises à jour comme suit :

    • Un nouveau champ JSON, stageKind, spécifie la zone de préparation.

    • Les champs objectName et objectId spécifient les valeurs correspondantes pour un utilisateur, une table et une zone de préparation nommée.

  • Pour plus de détails sur les opérations d’écriture prises en charge et non prises en charge, voir les remarques ci-dessous.

Remarques :

  • La colonne OBJECTS_MODIFIED renvoie un tableau au format suivant :

    {
      "columns": [
         {
           "columnName": <string>,
           "columnId": <number>
         },
         {
           "columnName": <string>,
           "columnId": <number>
         }
        ...
      ],
      "objectId": <number>,
      "objectName": <string>,
      "objectDomain": TABLE | STAGE,
      "location": <string>,
      "stageKind": Table | User | Internal Named | External Named
    }
    
    Copy

    S’il y a eu un accès à la zone de préparation dans la partie écriture de la requête :

    • La valeur de objectId est la suivante :

      • Identificateur NAME pour un utilisateur (zone de préparation de l’utilisateur).

      • Numéro TABLE_ID pour une table (zone de préparation de la table).

      • Numéro STAGE_ID pour une zone de préparation (zone de préparation nommée).

    • La valeur de objectName est la suivante :

      • Zone de préparation de l’utilisateur : la valeur est le username.

      • Zone de préparation de la table : la valeur est le table_name.

      • Zone de préparation nommée : la valeur est le stage_name.

  • S’il y a eu un accès à la zone de préparation dans la partie écriture de la requête, les colonnes BASE_OBJECTS_ACCESSED et DIRECT_OBJECTS_ACCESSED comprennent les champs JSON suivants :

    {
      "objectDomain": STAGE
      "objectName": <string>,
      "objectId": <number>,
      "stageKind": <string>
    }
    
    Copy

    Les valeurs possibles pour les noms de champs dans ces deux colonnes sont les mêmes que celles de la colonne OBJECTS_MODIFIED.

  • Snowflake prend en charge les opérations d’écriture suivantes dans la vue ACCESS_HISTORY :

    • GET <zone_de_préparation_interne>

    • PUT <zone_de_préparation_interne>

    • DELETE

    • INSERT

      • INSERT INTO … FROM SELECT *

      • INSERT INTO TABLE … VALUES ()

    • MERGE INTO … FROM SELECT *

    • UPDATE

      • UPDATE TABLE … FROM SELECT * FROM …

      • UPDATE TABLE … WHERE …

    • Instructions de chargement de données :

      • COPY INTO TABLE FROM internalStage

      • COPY INTO TABLE FROM externalStage

      • COPY INTO TABLE FROM externalLocation

    • Instructions de déchargement des données :

      • COPY INTO internalStage FROM TABLE

      • COPY INTO externalStage FROM TABLE

      • COPY INTO externalLocation FROM TABLE

    • CREATE:

      • CREATE DATABASE … CLONE

      • CREATE SCHEMA … CLONE

      • CREATE TABLE … CLONE

      • CREATE TABLE … AS SELECT

  • Snowflake ne prend pas en charge les opérations d’écriture suivantes dans la vue ACCESS_HISTORY :

    • Les opérations pour alimenter les vues, les vues matérialisées et les flux.

    • Mouvement de données résultant de la réplication.

COPY_HISTORY : cohérence de la casse des lettres de la colonne STATUS dans la sortie

Le statut d’un chargement de données est indiqué dans la colonne STATUS de la sortie de la fonction de table COPY_HISTORY dans l’Information Schema et dans le Vue COPY_HISTORY dans ACCOUNT_USAGE. Les valeurs renvoyées dans la colonne STATUS ont été modifiées comme suit :

Précédemment

Pour les chargements de données en masse (instructions COPY INTO <table>), les valeurs de statut étaient renvoyées avec la première lettre du premier mot en majuscule et les autres mots en minuscules, comme documenté : Loaded, Load failed, etc.

Pour les chargements de données Snowpipe, les valeurs de statut étaient renvoyées en majuscules : LOADED, LOAD FAILED, etc.

Actuellement

Pour les chargements de données en masse et Snowpipe, les valeurs de statut sont renvoyées avec la première lettre du premier mot en majuscule et les autres mots en minuscules.

Cette modification assure la cohérence des valeurs de la colonne STATUS et les met en conformité avec la documentation du produit.

Modifications de l’extensibilité

UDFs Java : modifications des critères d’inclusion des fichiers JAR Scala

Le comportement des UDF Java a changé comme suit :

Précédemment

Pour les UDFs Java, les fichiers JAR Scala étaient inclus dans le clathpass JVM.

Actuellement

Pour les UDFs Java, les bibliothèques Scala ne sont plus incluses dans le classpath. Si une partie de votre code UDF Java repose sur des bibliothèques Scala, incluez les fichiers JAR Scala dans la liste des importations lorsque vous créez de nouvelles UDFs ou remplacez des UDFs existants. Par exemple :

create or replace function add(x integer, y integer)
returns integer
language java
imports = ('@stage/scala-library-2.12.jar')
handler='TestAddFunc.add'
Copy

Les UDFs créées à l’aide de la bibliothèque Scala Snowpark ne sont pas affectées.

Modifications du chargement des données

Commande COPY INTO <table> : l’option de copie MATCH_BY_COLUMN_NAME renvoie une erreur lors du chargement de données CSV

L’option de copie MATCH_BY_COLUMN_NAME permet de charger des données semi-structurées dans des colonnes distinctes de la table cible qui correspondent aux colonnes correspondantes représentées dans les données source. L’option de copie ne prend pas en charge le chargement de données à partir de fichiers de valeurs séparées par des virgules (CSV).

Le comportement lors d’une tentative de chargement de données au format CSV avec l’option de copie MATCH_BY_COLUMN_NAME définie sur CASE_SENSITIVE ou CASE_INSENSITIVE a été modifié comme suit :

Précédemment

L’instruction COPY INTO <table> ne renvoyait pas d’erreur lorsqu’elle était utilisée avec les formats de fichier CSV, mais le paramètre MATCH_BY_COLUMN_NAME n’affectait pas le chargement des données et était ignoré.

Actuellement

L’instruction COPY INTO <table> renvoie une erreur utilisateur, car l’option ne prend pas en charge les fichiers CSV.

Commande COPY INTO <emplacement> : conversions explicites de colonnes ignorées lors du déchargement vers des données Parquet

Lors du déchargement de données de tables numériques vers des fichiers Parquet, l’appel de la fonction CAST dans l’instruction COPY INTO <emplacement> vous permet de choisir les types de données Snowflake qui correspondent aux types de données Parquet.

Le comportement lors de la conversion explicite de données de colonnes numériques vers des fichiers Parquet a été modifié comme suit :

Précédemment

Lorsqu’au moins une colonne numérique était explicitement convertie en un type de données qui ne correspondait pas à un type de données Parquet, l’opération de déchargement des données ignorait toutes les conversions explicites qui correspondaient à des types de données Parquet. Les colonnes de nombres à virgule fixe étaient déchargées en tant que colonnes DECIMAL, tandis que les colonnes de nombres à virgule flottante étaient déchargées en tant que colonnes DOUBLE.

Actuellement

Les opérations de déchargement des données respectent toutes les conversions explicites des données de colonnes numériques, que les types de données Snowflake cibles correspondent ou non à des types de données Parquet.

Modifications de Data Sharing

Comptes gérés : changement dans la prise en charge du nouveau format de nom de compte

Snowflake introduit une nouvelle URL basée sur un nom de compte géré mis à jour, que les clients peuvent choisir et modifier. L’URL a le format suivant :

<nom_de_l'organisation>-<nom_de_compte_géré>.snowflakecomputing.com

Le nouveau nom de compte géré comporte deux nouvelles règles de dénomination :

  • Le trait de soulignement (_) est le seul délimiteur valide dans le nom.

  • Le nom doit être unique à l’organisation dans laquelle se trouve le compte géré.

La plupart des noms de comptes gérés existants suivent déjà les nouvelles règles de dénomination et les noms resteront les mêmes. Les noms de comptes gérés qui ne respectaient pas ces règles étaient automatiquement mis à jour comme suit :

  • Si le nom de compte géré contenait des séparateurs autres que des traits de soulignement, ils étaient convertis en traits de soulignement. Par exemple, si le nom de compte géré était managed account-1, le nouveau nom de compte géré était managed_account_1.

  • Si le nom de compte géré n’était pas unique à l’organisation, le nom du localisateur était ajouté au nom de compte géré. Par exemple, si le nom de compte géré était managed avec un localisateur de RE47190, le nouveau nom de compte géré est managed_RE47190.

Le nom du compte géré mis à jour est utilisé dans toutes les commandes de compte géré :

  • CREATE MANAGED ACCOUNT applique les nouvelles règles de dénomination.

  • SHOW MANAGED ACCOUNTS affiche le nom de compte géré mis à jour dans la colonne du nom.

  • DROP MANAGED ACCOUNT utilise le nom de compte géré mis à jour comme paramètre.

Commande SHOW MANAGED ACCOUNTS : nouveau champ de nom de compte dans la sortie

La sortie de la commande SHOW MANAGED ACCOUNTS a changé comme suit :

Précédemment

La colonne URL affichait l’URL du localisateur de compte au format suivant :

<localisateur_compte>.snowflakecomputing.com

Actuellement

La colonne URL affiche l’URL du nom du compte en utilisant le nouveau format d’URL introduit dans la fonctionnalité Organisations. La nouvelle URL a le format suivant :

<nom_de_l'organisation>-<nom_de_compte_géré>.snowflakecomputing.com

En outre, la sortie comprend une nouvelle colonne, account_locator_url, pour afficher l’URL du localisateur de compte.

Note

En fonction de la région et de la plateforme Cloud où votre compte est hébergé, l’URL du localisateur de compte peut avoir des segments supplémentaires comme suit :

<localisateur_compte>.<code_région>.<cloud>.snowflakecomputing.com

L’URL du localisateur de compte existant continuera à fonctionner comme avant en plus de la nouvelle URL.

Commande SHOW SHARES et UI du partage de données : modifications de la sortie

La commande SHOW SHARES et l’interface Web pour le partage de données qui incluent un localisateur de compte (anciennement connu en tant que nom de compte généré automatiquement) dans la sortie ont été modifiées pour utiliser le nom de l’organisation et le nouveau nom de compte comme suit :

Précédemment

La colonne name affichait <localisateur_de_compte>.<nom_de_partage>

La colonne to (pour les partages sortants) affichait <localisateur_de_compte>

Actuellement

La colonne name affichera <nom_de_l'organisation>.<nom_du_compte>.<nom_du_partage>

La colonne to (pour les partages sortants) affichera <nom_de_l'organisation>.<nom_du_compte>

En outre, les commandes qui utilisent <localisateur_de_compte>.<nom_du_partage> comme paramètre (DESCRIBE SHARE et CREATE DATABASE … FROM SHARE) peuvent utiliser <nom_de_l'organisation>.<nom_du_compte>.<nom_du_partage> comme paramètre.

Pour plus d’informations sur la différence entre le localisateur de compte et le nouveau nom de compte, voir Identificateurs de compte.

Commandes SHOW et instructions SELECT : modifications de la sortie lorsque plusieurs partages proviennent de la même base de données

Précédemment

Lorsqu’un consommateur montait plus d’une base de données à partir de partages de données créés depuis la même base de données fournisseur (une configuration fournisseur de type une base de données pour plusieurs partages), dans certaines circonstances, les objets des partages de données d’origine identique apparaissaient à l’utilisateur de manière inattendue dans les bases de données montées basées sur ces partages de données d’origine identique. Ce problème n’avait pas d’impact réel l’accès réel aux données. Les objets apparaissaient de manière inattendue dans une base de données que l’utilisateur interrogeait uniquement s’il avait l’autorisation d’accéder à ces objets.

Par exemple, supposons qu’un fournisseur souhaite partager des données de ORIGIN_DATABASE. ORIGIN_DATABASE a deux schémas, SCHEMA_A et SCHEMA_Z. Le fournisseur veut partager trois tables. Deux tables sont issues de SCHEMA_A : SCHEMA_A.TABLE1 et SCHEMA_A.TABLE2. Le fournisseur veut aussi partager SCHEMA_Z.TABLE1.

Le fournisseur crée trois partages de données : FIRST_DATASHARE de SCHEMA_A.TABLE1, SECOND_DATASHARE de SCHEMA_A.TABLE2 et THIRD_DATASHARE de SCHEMA_Z.TABLE1. Le fournisseur ajoute ensuite un consommateur à ces trois partages.

Dans cet exemple, le consommateur a monté trois bases de données basées sur les partages de données du fournisseur : FIRST_DATABASE est montée à partir de FIRST_DATASHARE, SECOND_DATABASE à partir de SECOND_DATASHARE et THIRD_DATABASE à partir de THIRD_DATASHARE.

Dans cet exemple, le consommateur n’était pas forcément conscient que les bases de données qu’il avait montées étaient dérivées d’une base de données du fournisseur.

Lorsque le consommateur utilise SHOW OBJECTS (par exemple, TABLES, FUNCTIONS, etc.) pour explorer ses bases de données montées, il voit le même ensemble d’objets du même schéma d’origine dans chacune des bases de données montées, bien que les bases de données montées proviennent de partages différents.

Dans cet exemple, le consommateur a vu le résultat suivant en utilisant SHOW OBJECTS IN ACCOUNT. Dans le cadre de cet exemple, seules les colonnes pertinentes de la sortie sont incluses. Dans la sortie, les noms des bases de données sont remplacés par la base de données montée la plus récente d’origine identique.

name

database_name

schema_name

APPLICABLE_ROLES

THIRD_DATABASE

INFORMATION_SCHEMA

<autres objets info schema>

TABLE1

THIRD_DATABASE

SCHEMA_A

TABLE2

THIRD_DATABASE

SCHEMA_A

APPLICABLE_ROLES

THIRD_DATABASE

INFORMATION_SCHEMA

<autres objets info schema>

TABLE1

THIRD_DATABASE

SCHEMA_A

TABLE2

THIRD_DATABASE

SCHEMA_A

APPLICABLE_ROLES

THIRD_DATABASE

INFORMATION_SCHEMA

<autres objets info schema>

TABLE1

THIRD_DATABASE

SCHEMA_Z

Actuellement

Lorsqu’un consommateur monte des bases de données à partir de partages de données, le consommateur ne voit que les objets attendus par le fournisseur pour chaque partage de données, même si ces partages de données proviennent de la même base de données fournisseur.

Le consommateur, dans cet exemple, voit le résultat suivant après avoir utilisé SHOW OBJECTS IN ACCOUNT. Dans le cadre de cet exemple, seules les colonnes pertinentes de la sortie sont incluses.

name

database_name

schema_name

APPLICABLE_ROLES

FIRST_DATABASE

INFORMATION_SCHEMA

<autres objets info schema>

TABLE1

FIRST_DATABASE

SCHEMA_A

APPLICABLE_ROLES

SECOND_DATABASE

INFORMATION_SCHEMA

<autres objets info schema>

TABLE2

SECOND_DATABASE

SCHEMA_A

APPLICABLE_ROLES

THIRD_DATABASE

INFORMATION_SCHEMA

<autres objets info schema>

TABLE1

THIRD_DATABASE

SCHEMA_Z