Benutzerdefinierte Funktionen und gespeicherte Prozeduren in deklarativer Freigabe im Native Application Framework¶

Unterstützte benutzerdefinierte Funktionen und gespeicherte Prozeduren¶

Sie können die folgenden Arten von benutzerdefinierten Funktionen (UDFs) und gespeicherten Prozeduren (sprocs) in einer Declarative Native App freigeben:

• Gespeicherte Prozeduren, die OWNERS RIGHTS oder RESTRICTED CALLERS RIGHTS haben. Weitere

• Informationen finden Sie unter Erläuterungen zu gespeicherten Prozeduren mit Aufruferrechten und Eigentümerrechten.

• Alle Arten von UDFs, außer EXTERNAL Funktionen

Benutzerdefinierte Funktionen und gespeicherte Prozeduren in Ihre Anwendung einschließen¶

Um UDFs und gespeicherte Prozeduren in Ihre Declarative Native App einzuschließen, fügen Sie die Namen der Objekte und deren Berechtigungen zur manifest.yaml-Datei hinzu. Sie müssen die Objekte nicht über separate Dateien hinzufügen, wie es bei Notizbüchern der Fall ist.

Im folgenden Beispiel wird gezeigt, wie Sie eine UDF und eine gespeicherte Prozedur in der manifest.yaml-Datei einschließen:

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]

In diesem Beispiel werden die UDF POPULATION_ANALYSIS_FUNCTION und die gespeicherte Prozedur POPULATION_ANALYSIS_PROCEDURE in die:file:manifest.yaml-Datei aufgenommen. Die ANALYST-App-Rolle erhält Zugriff auf beide Objekte.

Zugriff auf private (nicht freigegebene) Objekte mit UDFs und gespeicherte Prozeduren¶

Sie können UDFs und gespeicherte Prozeduren für den Zugriff auf private (nicht freigegebene) Tabellen und Ansichten verwenden. Ihre Datenbank kann beispielsweise eine Ansicht enthalten, die für Verbrauchende nicht sichtbar ist, aber Verbrauchende können eine gespeicherte Prozedur verwenden, um Daten aus dieser Ansicht abzurufen.

Um Kunden Zugriff auf private Objekte über UDFs und gespeicherte Prozeduren zu ermöglichen, markieren Sie das Objekt mit dem Schlüsselwort private: true in der manifest.yaml-Datei.

Das folgende Beispiel zeigt, wie Sie einer gespeicherten Prozedur Zugriff auf eine private Tabelle in der manifest.yaml-Datei erlauben.

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]

Im vorherigen Beispiel ist die Ansicht COUNTRY_POP_BY_YEAR_2000 privat, weil keine Rollen Zugriff darauf erhalten haben, aber der Parameter private erlaubt es Logikobjekten, darauf zuzugreifen. Die VIEWER-App-Rolle kann die gespeicherte Prozedur ausführen, aber sie kann die private Ansicht nicht direkt abfragen. Beachten Sie, dass die Tabellen, auf die die Ansicht COUNTRY_POP_BY_YEAR_2000 verweist, nicht in die manifest.yaml-Datei aufgenommen werden müssen, damit die Ansicht darauf zugreifen kann.

Referenz zum Manifest¶

Dieses Feature fügt die folgenden Felder zur manifest.yaml-Datei hinzu:

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

Einschränkungen¶

Unterstützte Sprachen und Typen

Snowpark-UDFs und gespeicherte Prozeduren, die in Python, Java, Javascript oder Scala geschrieben sind. Funktionen des Snowpark Container Service werden nicht unterstützt.

Schemas für Daten- und Logikobjekte

Sie müssen separate Schemas für Datenobjekte (Tabellen und Ansichten) und Logikobjekte (UDFs und gespeicherte Prozeduren) verwenden. Sie könnten zum Beispiel ein Schema mit dem Namen DATA_SCHEMA für Tabellen und Ansichten sowie ein Schema namens LOGIC_SCHEMA für UDFs und gespeicherte Prozeduren verwenden.

Auf private Objekte verweisen

Ihre UDFs und gespeicherten Prozeduren müssen auf private Objekte über ihre vom Schema qualifizierten Namen verweisen. Ihre Logikobjekte können nicht über deren vollqualifizierte Namen auf private Objekte verweisen.

Objektanzahl

Eine Declarative Native App kann bis zu 100 UDFs und gespeicherte Prozeduren enthalten. Wenn Sie dieses Limit erhöhen möchten, wenden Sie sich an den Snowflake-Support.

Dynamische Tabellen

Das Verweisen auf dynamische Tabellen in UDFs und gespeicherten Prozeduren wird nicht unterstützt.