Limitações da UDF de Java¶
Este tópico descreve as limitações em vigor para manipuladores escritos em Java.
Neste tópico:
Limitações gerais¶
Embora seu método de Java possa usar classes e métodos nas bibliotecas padrão de Java, as limitações de segurança do Snowflake desabilitam algumas capacidades, tais como escrever em arquivos. Para obter mais detalhes, consulte a seção intitulada Boas práticas de segurança.
UDFs de Java não são compartilháveis. Objetos de banco de dados que usam UDFs de Java também não são compartilháveis. Por exemplo, você não pode:
Compartilhar diretamente uma UDF de Java.
Compartilhar uma exibição que chama uma UDF de Java.
Compartilhar uma função que chama uma UDF de Java.
Compartilhar uma tabela com uma política de acesso a linhas ou de mascaramento que chame uma UDF de Java.
A concessão de um privilégio de USAGE para uma UDF de Java pode permitir que o destinatário veja o conteúdo dos arquivos importados por essa UDF. Se você conceder o privilégio de USAGE para uma UDF de Java a uma função, e se essa função executar uma instrução que chama essa UDF de Java, qualquer UDF de Java na mesma instrução poderá ler o conteúdo de qualquer arquivo importado pela UDF de Java para a qual você concedeu o privilégio de USAGE.
A replicação ainda não inclui estágios externos ou internos. Quando você promove um banco de dados secundário para servir como banco de dados primário, você deve recriar objetos de preparação e reimportar quaisquer arquivos que faltem em estágios internos. Os arquivos devem ter o mesmo caminho e os mesmos nomes que no banco de dados primário original.
O tamanho máximo para uma linha de saída de uma UDF de Java é 16 MB.
Limitações da clonagem¶
Uma UDF de Java pode ser clonada quando o banco de dados ou esquema contendo a UDF de Java é clonado. Para ser clonada, a UDF de Java deve satisfazer a(s) seguinte(s) condição(ões):
Se a UDF de Java faz referência a um estágio (por exemplo, o estágio que contém o arquivo JAR da UDF), esse estágio deve estar fora do esquema (ou banco de dados) que está sendo clonado.
Você pode manter uma UDF de Java e seu(s) estágio(s) referenciado(s) em esquemas separados (e/ou bancos de dados separados) das seguintes maneiras:
Sempre que a UDF de Java fizer referência a um estágio, use um nome de estágio qualificado (por exemplo “my_db.my_schema.my_stage()”) diferente do esquema ou banco de dados da UDF de Java. Se a operação de clonagem clona um banco de dados, a referência do estágio deve incluir o banco de dados e o esquema. Se a operação de clonagem clonar um esquema, a referência do estágio deve incluir o esquema (e opcionalmente o banco de dados).
Crie o estágio referenciado usando um nome de estágio não qualificado (que implicitamente usa o banco de dados e esquema ativo da sessão atual) e crie a UDF de Java usando um nome qualificado que não corresponda ao banco de dados e esquema atual da sessão.
Use o estágio do usuário como o estágio referenciado (o estágio do usuário é separado de qualquer estágio ou esquema de banco de dados).
Se uma ou mais UDFs de Java no esquema ou banco de dados não satisfizerem as condições exigidas, o esquema ou banco de dados ainda poderá ser clonado, mas as UDFs de Java não conformes serão omitidas do clone sem nenhuma mensagem de erro ou advertência.
Cada UDF de Java clonada tem a mesma definição que a original. Essa definição inclui quaisquer referências a estágios. As referências a estágios na UDF de Java devem ser totalmente qualificadas e, portanto, são absolutas, não relativas ao esquema ou banco de dados que está sendo clonado. Porque tanto o original quanto o clone apontam para o(s) mesmo(s) estágio(s) e arquivo(s):
Remover o estágio ou remover arquivos necessários do estágio desativa tanto a UDF original quanto a clonada.
Alterar o estágio ou os arquivos no palco (por exemplo, substituir o arquivo JAR por um arquivo JAR mais recente) afeta tanto a UDF original quanto a clonada.
Para obter mais informações sobre clonagem, consulte Considerações sobre clonagem.