Limitations liées aux UDF

Cette rubrique décrit les limitations en vigueur pour les gestionnaires écrits en Java.

Dans ce chapitre :

Limitations générales

  • Bien que votre méthode Java puisse utiliser les classes et les méthodes des bibliothèques Java standard, les contraintes de sécurité de Snowflake désactivent certaines capacités, comme l’écriture dans des fichiers. Pour plus de détails, voir la section intitulée Respecter les bonnes pratiques de sécurité.

  • Les UDFs Java ne sont pas partageables. Les objets de la base de données qui utilisent des UDFs Java ne sont pas non plus partageables. Par exemple, vous ne pouvez pas :

    • Partager directement une UDF Java.

    • Partager une vue qui appelle une UDF Java.

    • Partager une fonction qui appelle une UDF Java.

    • Partager une table avec une politique de masquage ou d’accès aux lignes qui appelle une UDF Java.

  • Accorder le privilège USAGE sur une UDF Java peut permettre au destinataire de voir le contenu des fichiers importés par cette UDF. Si vous accordez le privilège USAGE sur une UDF Java à un rôle, et si ce rôle exécute une instruction qui appelle cette UDF Java, alors toute UDF Java dans la même instruction pourrait lire le contenu de tout fichier importé par l’UDF Java à laquelle vous avez accordé le privilège USAGE.

  • La réplication ne comprend pas encore de zones de préparation externes ou internes. Lorsque vous promouvez une base de données secondaire pour qu’elle serve de base de données principale, vous devez recréer des objets de zone de préparation et réimporter tous les fichiers manquants dans les zones de préparation internes. Les fichiers doivent avoir le même chemin et les mêmes noms de fichiers que dans la base de données principale d’origine.

  • La taille maximale d’une ligne de sortie UDF Java est de 16 MB.

Limites du clonage

Une UDF Java peut être clonée lorsque la base de données ou le schéma contenant l’UDF Java est cloné(e). Pour être clonée, l’UDF Java doit remplir la ou les conditions suivantes :

  • Si l’UDF Java fait référence à une zone de préparation (par exemple, la zone de préparation qui contient le fichier JAR de l’UDF), cette zone de préparation doit être extérieure au schéma (ou à la base de données) en cours de clonage.

    Vous pouvez conserver une UDF Java et une zone de préparation référencée (ou plusieurs) dans des schémas distincts (et/ou des bases de données distinctes) de l’une des manières suivantes :

    • Chaque fois que l’UDF Java fait référence à une zone de préparation, utilisez un nom de zone de préparation qualifié (par exemple, « mon_db.mon_schéma.ma_zone_préparation() ») différent du schéma ou de la base de données de l’UDF Java. Si l’opération de clonage clone une base de données, la référence de la zone de préparation doit inclure la base de données et le schéma. Si l’opération de clonage clone un schéma, la référence de la zone de préparation doit inclure le schéma (et éventuellement la base de données).

    • Créez la zone de préparation référencée en utilisant un nom de zone de préparation non qualifié (qui utilise implicitement la base de données et le schéma actifs de la session actuelle), et créez l’UDF Java en utilisant un nom qualifié qui ne correspond pas à la base de données et au schéma actuels de la session.

    • Utilisez la zone de préparation de l’utilisateur comme zone de préparation référencée (la zone de préparation de l’utilisateur est distincte de la zone de préparation de la base de données ou de la zone de préparation du schéma).

Si une ou plusieurs UDFs Java du schéma ou de la base de données ne remplissent pas les conditions requises, le schéma ou la base de données peut toujours être cloné(e), mais les UDFs Java non conformes sont omises du clone sans message d’erreur ou d’avertissement.

Chaque UDF Java clonée a la même définition que l’originale. Cette définition inclut toute référence aux zones de préparation. Les références de zones de préparation dans l’UDF Java doivent être entièrement qualifiées, et sont donc absolues, et non relatives au schéma ou à la base de données clonée. Parce que l’originale et le clone pointent tous deux vers la ou les mêmes zones de préparation et le ou les mêmes fichiers :

  • La destruction de la zone de préparation ou la suppression des fichiers requis de la zone de préparation désactive les UDF originales et clonées.

  • La modification de la zone de préparation ou des fichiers de la zone de préparation (par exemple, le remplacement du fichier JAR par un fichier JAR plus récent) affecte à la fois les UDF originales et clonées.

Pour plus d’informations sur le clonage, voir Remarques relatives au clonage.