ALTER ICEBERG TABLE … REFRESH¶

Syntaxe¶

ALTER ICEBERG TABLE [ IF EXISTS ] <table_name> REFRESH [ '<metadata_file_relative_path>' ]

Paramètres¶

table_name

Identificateur de la table à actualiser.

Si l’identificateur contient des espaces ou des caractères spéciaux, toute la chaîne doit être délimitée par des guillemets doubles. Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus d’informations, voir Exigences relatives à l’identificateur.

'metadata_file_relative_path'

Spécifie un chemin d’accès au fichier de métadonnées d’une table créée à partir de fichiers Iceberg dans le stockage d’objets. Le chemin d’accès doit être relatif à l”emplacement de stockage actif du volume externe associé à la table.

Le tableau suivant indique la valeur à spécifier en fonction d’un exemple d’emplacement de stockage :

Emplacement de stockage actif du volume externe de la table	s3://mybucket_us_east_1
Chemin d’accès complet au fichier de métadonnées	s3://mybucket_us_east_1/metadata/v1.metadata.json
Valeur à spécifier comme 'metadata_file_relative_path'	metadata/v1.metadata.json (sans barre oblique)

Note

• Si la table utilise AWS Glue comme catalogue, ou si elle est créée à partir de fichiers de table Delta, ne spécifiez pas de chemin d’accès au fichier de métadonnées.

• Omettez la barre oblique (/) dans le chemin d’accès au fichier de métadonnées.

• Avant la version 7.34 de Snowflake, un paramètre nommé BASE_LOCATION (également appelé FILE_PATH dans les versions précédentes) était nécessaire pour créer une table à partir de fichiers Iceberg dans le stockage d’objets. Le paramètre spécifiait un chemin d’accès relatif à partir de l’emplacement du EXTERNAL_VOLUME.

  Pour actualiser une table créée à l’aide de l’ancienne syntaxe, indiquez un chemin d’accès relatif à BASE_LOCATION. Par exemple, si le chemin d’accès complet à votre fichier de métadonnées est s3://mybucket_us_east_1/my_base_location/metadata/v1.metadata.json, indiquez metadata/v1.metadata.json comme metadata-file-relative-path.

Exigences en matière de contrôle d’accès¶

Un rôle utilisé pour exécuter cette commande SQL doit avoir les privilèges suivants définis au minimum ainsi :

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Notes sur l’utilisation¶

• Seul le propriétaire de la table (c’est-à-dire le rôle doté du privilège OWNERSHIP sur la table) ou un niveau supérieur peut exécuter cette commande.

• L’utilisation de la commande ALTER ICEBERG TABLE … REFRESH dans les transactions (implicites ou explicites) n’est pas prise en charge.

• L’actualisation des opérations pendant CREATE et ALTER … REFRESH peut traiter un maximum de 1 000 fichiers de validation Delta par opération.

  Note

  Snowflake utilise des fichiers de point de contrôle Delta lors de la création d’une table Iceberg. La limite de 1 000 fichiers de validation s’applique uniquement aux validations effectuées après le dernier point de contrôle.

• Concernant les métadonnées :

  Attention

  Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

Exemples¶

ALTER ICEBERG TABLE myIcebergTable REFRESH;

ALTER ICEBERG TABLE my_iceberg_table REFRESH 'path/to/metadata/v2.metadata.json';