Skip to main content
Los filtros acotan las filas que lee un job de extracción. Los adjuntas por campo, y Fetcher los convierte en una cláusula WHERE en un motor relacional o en un documento de consulta en MongoDB.

​
Dónde viven los filtros

Los filtros van junto a mappedFields en la solicitud, con cuatro niveles de profundidad: datasource, luego tabla, luego campo, luego el objeto del operador.
Todo datasource nombrado bajo filters debe aparecer también bajo mappedFields. El Manager rechaza un filtro que apunta a un datasource desconocido.

​
Los diez operadores

Cada operador toma un arreglo JSON, incluso cuando lleva un solo valor. El arreglo es la forma. Lo que cambia por operador es la cantidad de elementos. Ejemplos de cada forma:

​
Cómo se combinan los operadores

Puedes poner varios operadores sobre el mismo campo. Fetcher los combina todos con AND. El ejemplo { "gt": [100], "lte": [5000] } se lee como amount > 100 AND amount <= 5000. Los filtros sobre campos distintos también se combinan con AND. No hay OR entre campos. Usa in cuando necesites un OR sobre los valores de un mismo campo.

​
Reglas de validación

Fetcher rechaza un filtro antes de construir la consulta cuando la forma del valor es incorrecta:
  • between con una cantidad distinta de dos falla con between operator for field 'X' must have exactly 2 values, got N.
  • gt, gte, lt y lte con una cantidad distinta de uno fallan con el mensaje correspondiente a ese operador.
Los demás operadores toman la forma que les da la tabla:
  • like toma exactamente un patrón de texto.
  • eq, in, nin y ne toman uno o más valores.

​
Campos que parecen identificadores

En los motores relacionales, Fetcher inspecciona el nombre del campo. Un nombre que contiene id, _id, uuid, template_id, organization_id, user_id o account_id se trata como un campo UUID. Cada valor de texto bajo eq, gt, gte, lt, lte, between, in y nin debe entonces parsearse como UUID. Un valor que no se parsea hace fallar la solicitud y nombra el campo. Dos operadores quedan fuera de esta comprobación: ne y like. MongoDB no ejecuta la comprobación en absoluto.

​
Fechas en un filtro between

En los motores relacionales, Fetcher extiende el límite superior de un filtro between hasta el final del día cuando se cumplen tres cosas al mismo tiempo:
  1. El nombre del campo parece de fecha. Contiene date, time, _at, created_at, updated_at, deleted_at o completed_at.
  2. Ambos límites parecen cadenas de fecha.
  3. El límite superior tiene exactamente diez caracteres, en la forma YYYY-MM-DD.
Fetcher entonces reescribe el límite superior como YYYY-MM-DDT23:59:59.999Z. Por eso un filtro de ["2026-06-01", "2026-06-30"] incluye todo el 30 de junio. En MongoDB, ambos límites se aplican exactamente como los escribes. Para cubrir un día completo ahí, escribe el límite superior como una marca de tiempo completa: ["2026-06-01", "2026-06-30T23:59:59.999Z"].

​
Filtros en MongoDB

MongoDB toma los mismos diez operadores, y Fetcher los traduce a operadores de consulta: El patrón de like se vuelve una expresión regular: % pasa a .*, y _ pasa a .. Fetcher ancla el patrón al inicio salvo que abra con %, y al final salvo que cierre con %. La opción i hace que la coincidencia ignore mayúsculas y minúsculas.

​
Coincidencia de la clave de tabla

La clave de tabla bajo filters debe encontrar su tabla bajo mappedFields. PostgreSQL y SQL Server aceptan tres formas de la clave: el nombre exacto de la tabla, el nombre sin su prefijo de schema y el nombre con el schema por defecto añadido. Por eso un filtro con la clave transactions sigue aplicando a la tabla public.transactions. MySQL, Oracle y MongoDB comparan la clave de forma exacta. Escribe la clave tal como escribiste el nombre de la tabla o de la colección bajo mappedFields.

​
Próximos pasos

Jobs de extracción

La solicitud completa del job y el camino desde su creación hasta el resultado almacenado.

Fuentes de datos

Qué se comporta distinto en cada uno de los cinco motores de base de datos.