Fonctions définies par l’utilisateur et procédures stockées dans le partage déclaratif dans le Native Application Framework¶

Fonctions définies par l’utilisateur et procédures stockées prises en charge¶

Vous pouvez partager les types de fonctions définies par l’utilisateur (UDFs) et de procédures stockées (sprocs) suivants dans une Declarative Native App :

• Les procédures stockées qui disposent de OWNERS RIGHTS ou de RESTRICTED CALLERS RIGHTS. Pour

• plus d’informations, consultez Présentation des procédures stockées des droits de l’appelant et des droits du propriétaire.

• Tous les types d’UDFs, à l’exception des fonctions EXTERNAL.

Inclure des fonctions définies par l’utilisateur et des procédures stockées dans votre application¶

Pour inclure des UDFs et des procédures stockées dans votre Declarative Native App, ajoutez les noms des objets et leurs autorisations au fichier manifest.yaml. Vous n’avez pas besoin d’ajouter les objets en utilisant des fichiers séparés, comme vous le faites avec les notebooks.

L’exemple suivant montre comment inclure une UDF et une procédure stockée dans le fichier manifest.yaml :

manifest_version: 2

roles:
  - ANALYST:
      comment: "The ANALYST role provides access to logic objects."

shared_content:
  databases:
    - SNAF_POPULATION_DB:
        schemas:
          - LOGIC_SCHEMA:
              roles: [ANALYST]
              functions:
                - POPULATION_ANALYSIS_FUNCTION(NUMBER):
                    roles: [ANALYST]
              procedures:
                - POPULATION_ANALYSIS_PROCEDURE():
                    roles: [ANALYST]

Dans cet exemple, l’UDF POPULATION_ANALYSIS_FUNCTION et la procédure stockée POPULATION_ANALYSIS_PROCEDURE sont incluses dans le fichier manifest.yaml. Le rôle d’application ANALYST a accès aux deux objets.

Accès à des objets privés (non partagés) à l’aide d’UDFs et de procédures stockées¶

Vous pouvez utiliser des UDFs et des procédures stockées pour accéder à des tables et vues privées (non partagées). Par exemple, votre base de données peut contenir une vue qui n’est pas visible par les consommateurs, mais les consommateurs peuvent utiliser une procédure stockée pour récupérer des données à partir de cette vue.

Pour permettre aux clients d’accéder aux objets privés à l’aide d’UDFs et de procédures stockées, marquez l’objet avec le mot-clé private: true dans le fichier manifest.yaml.

L’exemple suivant montre comment autoriser une procédure stockée à accéder à une table privée dans le fichier manifest.yaml :

manifest_version: 2

roles:
  - VIEWER:
      comment: "The VIEWER role can access a stored procedure that retrieves data from a view, but not the underlying view."

shared_content:
  databases:
    - SNAF_POPULATION_DB:
        schemas:
          - DATA_SCHEMA:
              views: # This view is private as no roles are granted
                - COUNTRY_POP_BY_YEAR_2000:
                    private: true
          - LOGIC_SCHEMA:
              roles: [VIEWER]
              procedures:
                - POPULATION_DISPLAY_PROCEDURE():
                    roles: [VIEWER]

Dans l’exemple précédent, la vue COUNTRY_POP_BY_YEAR_2000 est privée, car aucun rôle n’y a accès, mais le paramètre private permet aux objets logiques d’y accéder. Le rôle d’application VIEWER peut exécuter la procédure stockée, mais ne peut pas interroger directement la vue privée. Notez que les tables référencées par la vue COUNTRY_POP_BY_YEAR_2000 n’ont pas besoin d’être incluses dans le fichier manifest.yaml pour que la vue puisse y accéder.

Référence du manifeste¶

Cette fonctionnalité ajoute les champs suivants au fichier manifest.yaml :

manifest_version: 2

roles:
  - VIEWER:
      comment: "The VIEWER role provides access to only one view."
  - ANALYST:
      comment: "The ANALYST role provides access to views, the table, and logic."

shared_content:
  databases:
    - SNAF_POPULATION_DB:
        schemas:
          - DATA_SCHEMA:
              roles: [VIEWER, ANALYST]
              tables:
                - COUNTRY_POP_BY_YEAR:
                    roles: [ANALYST]
              views:
                - COUNTRY_POP_BY_YEAR_2000:
                    roles: [VIEWER, ANALYST]
          - LOGIC_SCHEMA:
              roles: [ANALYST]
              functions:
                - POPULATION_ANALYSIS_FUNCTION(NUMBER):
                    roles: [ANALYST]
              procedures:
                - POPULATION_ANALYSIS_PROCEDURE():
                    roles: [ANALYST]
application_content:
  notebooks:
      - intro_notebook:
          roles: [VIEWER, ANALYST]
          main_file: INTRO_NB.ipynb
      - analyst_notebook:
          roles: [ANALYST]
          main_file: ANALYST_NB.ipynb

Limitations¶

Langages et types pris en charge

Les UDFs et les procédures stockées Snowpark écrites en Python, Java, Javascript et Scala. Les fonctions Snowpark Container Service ne sont pas prises en charge.

Schémas pour les objets de données et les objets logiques

Vous devez utiliser des schémas distincts pour les objets de données (tables et vues) et les objets logiques (UDFs et procédures stockées). Par exemple, vous pouvez utiliser un schéma nommé DATA_SCHEMA pour les tables et les vues, et un schéma nommé LOGIC_SCHEMA pour les UDFs et les procédures stockées.

Référencement d’objets privés

Vos UDFs et vos procédures stockées doivent référencer les objets privés par leurs noms qualifiés par schéma. Vos objets logiques ne peuvent pas référencer des objets privés par leurs noms pleinement qualifiés.

Nombre d’objets

Une Declarative Native App peut inclure jusqu’à 100 UDFs et procédures stockées. Pour augmenter cette limite, contactez le support Snowflake.

Tables dynamiques

Le référencement des tables dynamiques dans les UDFs et les procédures stockées n’est pas pris en charge.