O que todo motor compartilha
Defina o motor pelo
type da conexão, em maiúsculas: POSTGRESQL, MYSQL, ORACLE, SQL_SERVER, MONGODB. A validação da requisição compara exatamente essas cinco cadeias, então qualquer outra capitalização falha com 400.
Estes limites são os mesmos em todos os motores:
Os quatro motores relacionais compartilham um mesmo perfil de pool de conexões: 25 conexões abertas, 10 conexões ociosas, tempo de vida de conexão de 5 minutos e tempo limite de ociosidade de 1 minuto. O MongoDB usa um pool de no máximo 100 e no mínimo 10, com o mesmo tempo limite de ociosidade de 1 minuto.
A projeção de campos também funciona da mesma forma. Uma lista de nomes de campos seleciona esses campos. A entrada única
["*"] seleciona todos eles.
PostgreSQL
Esquemas. O PostgreSQL é o motor multiesquema mais completo no Fetcher. A descoberta lê o
information_schema para os esquemas que o seu job nomeia, e recorre a public quando o job não nomeia nenhum.
Nomes de tabelas. Uma tabela fora de public volta qualificada pelo esquema, como accounting.invoices. Uma tabela dentro de public volta sem qualificação, como users. Escreva o nome da mesma forma em mappedFields.
Chaves de filtro. Uma chave de filtro resolve em três formas: o nome exato, o nome sem o prefixo de esquema e o nome com public acrescentado. transactions e public.transactions portanto chegam à mesma tabela.
Colunas JSON. O driver retorna colunas JSON e JSONB como bytes brutos. O Fetcher tenta ler cada valor como objeto JSON, depois como array JSON, depois como string JSON. O valor convertido entra no resultado. Um valor que não casa com nenhum dos três permanece bruto, e o Fetcher registra um aviso em log.
MySQL
Sem lista de esquemas. O MySQL é o único motor relacional sem dimensão de esquema no Fetcher. O banco de dados conectado é o namespace. A descoberta lê o
information_schema em busca de tabelas, colunas e chaves primárias desse banco.
Nomes de tabelas. Escreva os nomes de tabelas sem qualificação. Um prefixo de esquema não tem contra o que resolver.
Chaves de filtro. Uma chave de filtro precisa casar com o nome da tabela exatamente como você o escreveu em mappedFields.
Colunas JSON. O Fetcher aplica aos valores em bytes a mesma leitura JSON em três passos que aplica no PostgreSQL: objeto, depois array, depois string.
Oracle
Owners, não esquemas. O Oracle chama o namespace de owner, e o Fetcher trata o owner como o esquema. Quando o seu job nomeia owners, a descoberta lê
all_tables, all_tab_columns e all_cons_columns restritos a esses owners. Quando não nomeia nenhum, a descoberta recorre a user_tables e user_cons_columns, que cobrem apenas o usuário conectado.
O owner padrão é o usuário com que a conexão se autentica.
Nomes de tabelas. Uma tabela cujo owner é o usuário conectado volta sem qualificação. Qualquer outra tabela volta qualificada pelo owner, como OWNER.TABLE. O Fetcher compara nomes de owner sem diferenciar maiúsculas e minúsculas, e converte o owner para maiúsculas antes de consultar o catálogo do Oracle. O Fetcher também converte para maiúsculas os nomes de tabelas e de colunas no esquema que ele reporta de volta, e as linhas extraídas usam esses nomes de colunas em maiúsculas como chaves. Você pode escrever um job em maiúsculas ou em minúsculas, porque o Fetcher converte os nomes da sua requisição da mesma forma. Leia os resultados pela chave em maiúsculas.
Chaves de filtro. O Oracle faz a correspondência exata da chave de filtro. Não há fallback de prefixo.
Colunas JSON. Valores em bytes passam pela mesma leitura JSON em três passos.
SQL Server
Esquemas. O SQL Server é multiesquema, com
dbo como padrão. A descoberta lê o information_schema.tables para os esquemas que o seu job nomeia, e se restringe a dbo quando o job não nomeia nenhum.
Nomes de tabelas. Uma tabela fora de dbo volta qualificada pelo esquema, como accounting.invoices. Uma tabela dentro de dbo volta sem qualificação. É a mesma regra que o PostgreSQL aplica a public.
Chaves de filtro. O SQL Server resolve uma chave de filtro nas mesmas três formas do PostgreSQL, com dbo como prefixo padrão.
Colunas JSON. Valores em bytes passam pela mesma leitura JSON em três passos.
MongoDB
Coleções, não tabelas. O MongoDB não tem namespace de esquema. Escreva os nomes de coleção sem qualificação. Uma chave de filtro precisa casar exatamente com o nome da coleção. Esquema inferido. Documentos não carregam esquema declarado, então o Fetcher monta um em duas passagens sobre cada coleção:
- Um pipeline de agregação reúne o conjunto completo de nomes de campos.
- Uma amostra de até 50 documentos infere o tipo de cada campo. Um campo que a amostra nunca vê fica com o tipo
unknown.
$sample, com um tamanho que mira 95% de confiança e 5% de margem de erro:
Um esquema inferido é, portanto, uma amostra forte, não uma garantia. Um campo que existe em um punhado de documentos de uma coleção muito grande pode passar despercebido. Se a agregação falhar em uma coleção, o Fetcher registra um aviso em log e recorre à amostragem em vez de falhar a descoberta.
Filtros. O MongoDB aceita os mesmos dez operadores, traduzidos para operadores de consulta. Um padrão de
like vira uma expressão regular insensível a maiúsculas e minúsculas. O MongoDB também é o único motor que não executa a verificação de UUID em nomes de campos que parecem identificadores. Veja Filtros.
Opções de conexão. Uma fonte de dados interna passa opções de driver como authSource e directConnection por meio de DATASOURCE_{NAME}_OPTIONS.
Próximos passos
Jobs de extração
Como um job nomeia fontes de dados, tabelas, esquemas e campos.
Filtros
Os dez operadores de filtro e o formato de valor que cada um aceita.