Funções definidas pelo usuário e procedimentos armazenados no compartilhamento declarativo no Native Application Framework¶

Funções definidas pelo usuário e procedimentos armazenados compatíveis¶

Você pode compartilhar os seguintes tipos de funções definidas pelo usuário (UDFs) e procedimentos armazenados (sprocs) em um Declarative Native App:

• Procedimentos armazenados com OWNERS RIGHTS ou RESTRICTED CALLERS RIGHTS. Para

• obter mais informações, consulte Procedimentos armazenados com direitos do autor da chamada e direitos do proprietário.

• Todos os tipos de UDFs, exceto funções EXTERNAL

Inclusão de funções definidas pelo usuário e procedimentos armazenados em seu aplicativo¶

Para incluir UDFs e procedimentos armazenados em seu Declarative Native App, adicione os nomes dos objetos e as respectivas permissões ao arquivo manifest.yaml. Você não precisa adicionar os objetos usando arquivos separados, como faz com os notebooks.

O exemplo a seguir mostra como incluir uma UDF e um procedimento armazenado no arquivo 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]

Neste exemplo, a UDF POPULATION_ANALYSIS_FUNCTION e o procedimento armazenado POPULATION_ANALYSIS_PROCEDURE estão incluídos no arquivo manifest.yaml. A função ANALYST do app recebe acesso a ambos os objetos.

Acesso a objetos privados (não compartilhados) usando UDFs e procedimentos armazenados¶

Você pode usar UDFs e procedimentos armazenados para acessar tabelas e exibições privadas (não compartilhadas). Por exemplo, seu banco de dados pode ter uma exibição que não fique visível aos consumidores, mas os consumidores podem usar um procedimento armazenado para recuperar os dados dessa exibição.

Para permitir que os clientes acessem objetos privados usando UDFs e procedimentos armazenados, marque o objeto com a palavra-chave private: true no arquivo manifest.yaml.

O exemplo a seguir mostra como permitir que um procedimento armazenado acesse uma tabela privada no arquivo 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]

No exemplo anterior, a exibição COUNTRY_POP_BY_YEAR_2000 é privada porque nenhuma função recebeu acesso a ela, mas o parâmetro private permite que objetos lógicos a acessem. A função VIEWER do app pode executar o procedimento armazenado, mas não pode consultar a exibição privada diretamente. Observe que as tabelas às quais a exibição COUNTRY_POP_BY_YEAR_2000 faz referência não precisam ser incluídas no arquivo manifest.yaml para que a exibição as acesse.

Referência do manifesto¶

Esse recurso adiciona os seguintes campos ao arquivo 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

Limitações¶

Linguagens e tipos compatíveis

UDFs e procedimentos armazenados do Snowpark escritos em Python, Java, Javascript e Scala. Funções do Snowpark Container Services não são compatíveis.

Esquemas para objetos de dados e lógicos

Você deve usar esquemas separados para objetos de dados (tabelas e exibições) e objetos lógicos (UDFs e procedimentos armazenados). Por exemplo, você pode usar um esquema chamado DATA_SCHEMA para tabelas e exibições, e um esquema chamado LOGIC_SCHEMA para UDFs e procedimentos armazenados.

Referência a objetos privados

As UDFs e os procedimentos armazenados devem fazer referência a objetos privados pelos respectivos nomes qualificados. Os objetos lógicos não podem fazer referência a objetos privados pelos nomes totalmente qualificados.

Contagem de objetos

Um Declarative Native App pode incluir até 100 UDFs e procedimentos armazenados. Para aumentar esse limite, entre em contato com o suporte Snowflake.

Tabelas dinâmicas

A referência a tabelas dinâmicas em UDFs e procedimentos armazenados não é permitida.