Filtros

Los diez operadores de filtro de Fetcher, sus formas de valor y cómo los aplica cada datasource.

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.

{
  "dataRequest": {
    "mappedFields": {
      "my_postgres": { "transactions": ["id", "amount", "status", "created_at"] }
    },
    "filters": {
      "my_postgres": {
        "transactions": {
          "status": { "in": ["completed", "pending"] },
          "amount": { "gt": [100], "lte": [5000] },
          "created_at": { "between": ["2026-06-01", "2026-06-30"] }
        }
      }
    }
  }
}

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.

Operador	Forma del valor	Resultado
eq	Uno o más valores	Un valor coincide con =. Dos o más se vuelven IN (…).
gt	Exactamente un valor	field > value
gte	Exactamente un valor	field >= value
lt	Exactamente un valor	field < value
lte	Exactamente un valor	field <= value
between	Exactamente dos valores, [min, max]	field >= min AND field <= max, inclusivo en ambos extremos.
in	Uno o más valores	field IN (…)
nin	Uno o más valores	field NOT IN (…)
ne	Uno o más valores	Un valor da field <> value. Cada valor extra añade otra condición <>.
like	Un patrón de texto	field LIKE pattern, con los comodines SQL % y _.

Ejemplos de cada forma:

{
  "status":      { "eq": ["active", "pending"] },
  "amount":      { "gt": [100] },
  "created_at":  { "gte": ["2026-06-01"] },
  "total":       { "lt": [1000] },
  "closed_at":   { "lte": ["2026-06-30"] },
  "value":       { "between": [100, 1000] },
  "state":       { "in": ["active", "pending", "suspended"] },
  "state_two":   { "nin": ["deleted", "archived"] },
  "kind":        { "ne": ["internal"] },
  "description": { "like": ["%refund%"] }
}

​

Cómo se combinan los operadores

---

En los motores relacionales, los operadores no vacíos que se aplican sobre el mismo campo se combinan con AND. El ejemplo { "gt": [100], "lte": [5000] } se lee como amount > 100 AND amount <= 5000.

El adaptador actual de MongoDB no combina de forma segura eq con otro operador del mismo campo, ni dos operadores que escriben la misma clave de MongoDB. Una asignación posterior puede reemplazar la condición anterior. Usa un operador no conflictivo por campo de MongoDB.

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

---

Para arreglos no vacíos, Fetcher valida between con dos valores y gt, gte, lt y lte con uno. Los arreglos vacíos no agregan ninguna condición.

like solo se aplica cuando su primer valor es texto. Los valores extra, un arreglo vacío y un primer valor no textual hoy se ignoran en lugar de rechazarse. eq, in, nin y ne usan los valores recibidos cuando el arreglo no está vacío.

​

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 cumplen la heurística de texto parecido a fecha de Fetcher: tienen al menos diez caracteres, contienen un guion y tienen exactamente diez caracteres o contienen una T.
3. El límite superior tiene diez caracteres.

Es una heurística de nombre de campo y forma del texto, no una validación de fecha calendario. Cuando se aplica, Fetcher reescribe el límite superior como YYYY-MM-DDT23:59:59.999Z.

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:

Operador	Forma en MongoDB
eq con un valor	{ "field": value }
eq con dos o más	$in
gt, gte, lt, lte	$gt, $gte, $lt, $lte
between	$gte y $lte
in	$in
nin	$nin
ne con un valor	$ne
ne con dos o más	$nin
like	$regex con la opción i

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 y MongoDB comparan la clave literalmente. Oracle normaliza los identificadores a mayúsculas, así que la coincidencia de clave de tabla no distingue mayúsculas y minúsculas; no agrega ni elimina un schema predeterminado.

​

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.