> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Jobs de extração > Como um job de extração do Fetcher descreve fontes de dados, tabelas, esquemas e campos — e o que acontece com o job da criação até o resultado armazenado. Um job de extração é uma requisição assíncrona para ler dados de um ou mais bancos de dados registrados. O Manager aceita o job e o coloca na fila. Um Worker executa a extração e armazena o resultado. Esta página explica a requisição que você envia e o caminho que o job percorre. ## A requisição *** Um job carrega duas partes: `dataRequest` e `metadata`. ```json theme={null} { "dataRequest": { "mappedFields": { "my_postgres": { "public.accounts": ["id", "email", "created_at"], "accounting.invoices": ["*"] }, "my_mongo": { "transactions": ["*"] } } }, "metadata": { "source": "payments", "correlationId": "settlement-2026-07-13" } } ``` `mappedFields` é o coração da requisição. Ele mapeia o nome de configuração de cada fonte de dados para as tabelas que você quer, e cada tabela para os campos que você quer. `metadata.source` é **obrigatório**. Ele nomeia o produto dono do job. O Manager rejeita uma requisição sem esse campo. O Manager também rejeita a requisição quando uma conexão referenciada pertence a outro produto, ou não pertence a produto algum. Fontes de dados internas não carregam produto, então essa verificação não se aplica a elas. ## Projeção de campos *** Nomeie os campos que você quer, ou peça todos eles: * Uma lista de nomes de campos extrai exatamente esses campos. * A entrada única `["*"]` extrai todas as colunas da tabela. O curinga precisa ser a única entrada da lista. O Fetcher valida cada campo nomeado contra o esquema descoberto antes de consultar. Um nome de campo desconhecido faz o job falhar e nomeia os campos problemáticos no erro. Uma tabela sem nenhum campo válido também faz o job falhar. ## Múltiplas fontes de dados, tabelas e esquemas *** Um job pode ler de várias fontes de dados ao mesmo tempo. Cada fonte de dados pode contribuir com várias tabelas. Cada tabela pode estar em um esquema diferente. Escreva o nome de uma tabela em uma de duas formas: * **Sem qualificação** — `accounts`. O Fetcher a lê no esquema padrão do motor: `public` no PostgreSQL, `dbo` no SQL Server. * **Qualificada pelo esquema** — `accounting.invoices`. O prefixo antes do ponto é o esquema. No Oracle, é o owner. O Fetcher reúne os prefixos de esquema distintos em `mappedFields` e descobre apenas esses namespaces. Se algum nome de tabela vier sem qualificação, a descoberta acrescenta também o esquema padrão do motor: `public` no PostgreSQL, `dbo` no SQL Server. Dois motores não recebem lista de esquemas. O MySQL trata o banco de dados conectado como o namespace. O MongoDB tem coleções em vez de esquemas, então um nome de coleção nunca leva qualificação. ## Limites *** O motor de extração limita todo job. Estes são os valores padrão: | Limite | Padrão | | ------------------------------------- | --------- | | Fontes de dados por job | 10 | | Tabelas por fonte de dados | 20 | | Campos por tabela | 50 | | Fontes de dados extraídas em paralelo | 4 | | Tempo limite de extração | 5 minutos | | Tamanho do resultado serializado | 256 MiB | O Manager rejeita um job com mais de 10 fontes de dados antes que ele chegue à fila. Um resultado acima do limite de tamanho faz o job falhar. O Fetcher nunca retorna nem armazena um resultado truncado. `ENGINE_MAX_RESULT_BYTES` baixa o teto de tamanho no Worker. Uma requisição pode reduzir um limite, mas nunca elevá-lo acima do padrão do motor. ## Jobs duplicados *** O Manager calcula um hash SHA-256 sobre a requisição inteira — `dataRequest` e `metadata` juntos. Em seguida, procura um job com o mesmo hash criado nos últimos **5 minutos**. * Uma correspondência retorna o job existente com HTTP 200. Nenhuma segunda extração roda. * Sem correspondência, o Manager cria um novo job e retorna HTTP 202. * Uma correspondência que já **falhou** não bloqueia uma nova tentativa. O Manager cria um novo job. O metadata faz parte do hash. Duas requisições que leem os mesmos dados sob correlation IDs diferentes são jobs diferentes. ## Ciclo de vida do job *** | Status | Significado | | ------------ | ----------------------------------------------------------- | | `pending` | O Manager aceitou o job e o publicou na fila. | | `processing` | Um Worker assumiu o job e lê as fontes de dados. | | `completed` | O resultado está armazenado, e `job.completed` é publicado. | | `failed` | A extração parou, e `job.failed` é publicado. | Antes de criar o job, o Manager resolve cada nome de fonte de dados para uma conexão e abre uma conexão real com cada uma. Uma fonte de dados que falha nesse teste rejeita a requisição inteira. Fontes de dados internas configuradas por variáveis de ambiente não passam por esse teste. Um Worker assume um job apenas enquanto ele ainda está `pending`. Depois, move o job para `processing` e inicia a extração. As fontes de dados rodam em paralelo até o limite de concorrência. A execução é fail-fast: a primeira fonte de dados que falha encerra o job, e o Fetcher não armazena resultado parcial. Em caso de sucesso, o Worker escreve o resultado no object storage e registra dois valores no job: o caminho do resultado e a assinatura HMAC do resultado. Em seguida, publica o evento terminal. ## Próximos passos *** Os dez operadores de filtro e o formato de valor que cada um aceita. O que se comporta de forma diferente em cada um dos cinco motores de banco de dados.