Ir para o conteúdo

mvSQL no Jitterbit App Builder

Visão geral

mvSQL é o dialeto SQL próprio do App Builder. Permite que os usuários aprendam e usem um único conjunto de sintaxe e funções, enquanto o App Builder traduz essa sintaxe para expressões apropriadas do fornecedor. mvSQL pode ser usado para consultar banco de dados relacional, armazenamento, REST, sistemas de arquivos ou qualquer outro tipo de provedor de dados que o App Builder suporta.

Versões do mvSQL

As versões do mvSQL suportadas pelo App Builder são listadas com a versão mais antiga suportada aparecendo primeiro (Versão 1).

Versão 1

A versão legada mais antiga que o App Builder suporta, a Versão 1 do mvSQL é ainda mais rigorosa do que permitíamos antes de refatorar a gramática e o analisador. A maioria dos aplicativos legados do App Builder deve ser executada usando esta versão.

Versão 2

O mvSQL Versão 2 melhora a sintaxe de passthrough, suporta a capacidade de fechá-la e retomar expressões mvSQL regulares, e suporta caracteres de escape.

Exemplo

A Versão 1 veria isto (no MS SQL Server) ${ [vendor syntax] } || 'my example' como ${ [vendor syntax] || 'my example' } renderizando [vendor syntax] || 'my example'.

A Versão 2 analisaria como deveria ser, e renderizaria como [vendor syntax] + 'my example'. Observe a concatenação sendo apropriada ao fornecedor).

Versão 3

O mvSQL Versão 3 requer que os prefixos de tabela estejam corretos. Até esta versão, se o prefixo da tabela estivesse incorreto, e o App Builder pudesse inferir verificando as outras colunas, permitiríamos prefixos de tabela incorretos.

Exemplo

Em versões anteriores do mvSQL, usar um alias de tabela que não existe, ou até mesmo um que existe mas que não possui a coluna referenciada, ainda funcionaria desde que esse nome de coluna aparecesse em apenas uma das fontes. Este cenário apresenta um problema quando esse mesmo nome de coluna é adicionado a outra fonte e a regra de negócio para de funcionar.

Versão 4

Na Versão 4 do mvSQL, as funções de Runtime produzem um tipo apropriado, em vez de sempre serem uma string, e valores nulos não são coalesced em uma string vazia.

Exemplo

Shared(ColumnName, numeric)

  • Antes da versão 4, o App Builder produziria '0' se a coluna não fosse fornecida, ou '1' se fosse (observe que é renderizado como uma string, assumindo que o valor compartilhado aqui é 1 é claro)
  • A partir da versão 4, o App Builder agora produz null se não foi fornecido, e 1 (sem aspas), também parametrizamos se o fornecedor suporta (@p0), pois isso pode aproveitar melhor desempenho do fornecedor.
  • Isso também significa que é mais fácil fazer coalesce do valor, antes se você quisesse alterar o valor se não fosse fornecido, precisaria de algo como IIF(Shared(ColumnName) = '', -1, Shared(ColumnName, numeric)), agora você pode usar ISNULL(Shared(ColumnName, numeric), -1)
  • Novas regras são criadas usando a versão mais alta disponível (versão 4), mas para evitar quebrar regras legadas, mantivemos como estavam. Se forem feitas alterações em uma regra que não serão afetadas por isso (principalmente regras sem funções de runtime), o App Builder atualizará automaticamente a versão do mvSQL.

Versão 5

Na versão 5, mvSQL trata qualquer passthrough como GROUP-able quando faz parte de uma consulta agregada.

Para indicar que uma expressão é um agregado, chame-a com a função Expression().

Exemplo

Expression(${Count(1)})

Expressões de passthrough

Expressões de passthrough usam a sintaxe ${...} para injetar SQL específico do fornecedor em uma consulta mvSQL (consulte Escapando SQL para detalhes de sintaxe). Como expressões de passthrough são específicas do fornecedor, não são portáveis entre tipos de banco de dados, portanto seu uso é desaconselhado. Se você pode usar expressões de passthrough depende da sua versão do App Builder:

  • No App Builder 4.65 e anterior, expressões de passthrough podem ser usadas.

  • No App Builder 4.66 e posterior, você deve ativar a opção Allow Passthrough Expressions na aba Data Sources do App Workbench para manter regras contendo expressões de passthrough válidas. Caso contrário, o App Builder ainda permite que você salve tal regra, mas a marca como inválida quando você executa Validate Rules ou visualiza os resultados da regra.

Recursos