> ## 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, 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. ```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 *** 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 *** La solicitud completa del job y el camino desde su creación hasta el resultado almacenado. Qué se comporta distinto en cada uno de los cinco motores de base de datos.