Limites liées aux UDF Scala

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

Limitations générales

  • Bien que votre méthode Scala puisse utiliser les classes et les méthodes des bibliothèques Scala 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 Pratiques de sécurité pour UDFs et procédures.

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

    • Partagez directement une UDF Scala.

    • Partagez une vue qui appelle une UDF Scala.

    • Partagez une fonction qui appelle une UDF Scala.

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

  • Accorder le privilège USAGE sur une UDF Scala 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 Scala à un rôle, et si ce rôle exécute une instruction qui appelle cette UDF Scala, alors toute UDF Scala dans la même instruction pourrait lire le contenu de tout fichier importé par l’UDF Scala à laquelle vous avez accordé le privilège USAGE.

  • La réplication de la base de données 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 Scala est de 16 MB.

  • La simultanéité n’est pas prise en charge. Par exemple, à partir de votre code, vous ne pouvez pas soumettre de requêtes à partir de plusieurs threads. Le code qui émet simultanément plusieurs requêtes produira une erreur.

  • Si une requête appelle une UDF pour accéder à des fichiers en zone de préparation, l’opération échoue avec une erreur utilisateur si l’instruction SQL interroge également une vue qui appelle une UDF, que la fonction de la vue accède ou non à des fichiers en zone de préparation.

  • Les UDFs traitent actuellement les fichiers en série. Comme solution de rechange, regroupez les lignes dans une sous-requête en utilisant la clause GROUP BY.

  • Actuellement, si les fichiers en zone de préparation référencés dans une requête sont modifiés ou supprimés pendant l’exécution de la requête, l’appel de la fonction renvoie une erreur.

Limites du clonage

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

  • Si l’UDF Scala 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 Scala et sa 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 Scala fait référence à une zone de préparation, utilisez un nom de zone de préparation qualifié (par exemple, my_db.my_schema.my_stage) différent du schéma ou de la base de données de l’UDF Scala. 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 Scala 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 Scala 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 Scala non conformes sont omises du clone sans message d’erreur ou d’avertissement.

Chaque UDF Scala 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 Scala 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.