> ## 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.

# Filtros

> Los diez operadores de filtro de Fetcher, la forma de valor exacta que toma cada uno y las reglas de validación que rechazan un filtro mal formado.

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.

```json theme={null}
{
  "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:

```json theme={null}
{
  "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

***

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:

| 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, 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

***

<CardGroup cols={2}>
  <Card title="Jobs de extracción" icon="list-check" href="/es/fetcher/fetcher-extraction-jobs">
    La solicitud completa del job y el camino desde su creación hasta el resultado almacenado.
  </Card>

  <Card title="Fuentes de datos" icon="database" href="/es/fetcher/fetcher-datasources">
    Qué se comporta distinto en cada uno de los cinco motores de base de datos.
  </Card>
</CardGroup>
