> ## 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. # Descubrimiento de esquemas > Cómo Fetcher lee las tablas y los campos de un datasource, cuándo sirve un snapshot en caché y cómo valida un mapeo de extracción antes de la primera consulta. Fetcher lee la forma de un datasource por ti. Un **snapshot de esquema** lista las tablas de un datasource y los nombres de campo de cada tabla. No mantienes ningún catálogo aparte, y no subes ningún archivo de esquema. Dos tareas dependen de un snapshot. Quien llama lee uno para saber qué campos existen. La extracción genérica valida las tablas y los campos seleccionados durante la planificación antes de consultar datos. Esa validación usa un snapshot con caché primero, por lo que un acierto de caché no es una comprobación contra el esquema vivo. La ruta de compatibilidad `plugin_crm` es separada. ## Qué guarda un snapshot *** | Elemento | Contenido | | ------------ | ------------------------------------------------------------- | | `configName` | La conexión que describe el snapshot. | | Tablas | Una entrada por tabla o colección, bajo su nombre calificado. | | Campos | Los nombres de campo de cada tabla, en orden alfabético. | Los nombres llegan calificados cuando la tabla está fuera del espacio de nombres por defecto. PostgreSQL devuelve `accounting.invoices` para una tabla en otro esquema y `users` a secas para una en `public`. SQL Server aplica la misma regla alrededor de `dbo`. Oracle devuelve `OWNER.TABLE` cuando el propietario difiere del usuario conectado. Un snapshot lleva nombres y nada más. No guarda filas, ni credenciales, ni cadena de conexión. Las tablas de sistema nunca llegan a él: el adaptador de base de datos descarta `pg_*`, `information_schema` y las vistas del diccionario de Oracle antes de que el snapshot salga del adaptador. ## Descubrimiento en vivo y descubrimiento en caché *** El Manager expone dos superficies de esquema, y difieren a propósito. | Operación | Frescura | | ------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | `GET /v1/management/connections/{id}/schema` | Siempre en vivo. Nunca lee la caché ni escribe en ella. | | `POST /v1/management/connections/validate-schema` | Caché primero. Sirve un snapshot en caché cuando existe, y descubre en vivo en caso contrario. | La división sigue los dos casos de uso. Quien pide un esquema quiere la verdad actual, a menudo justo después de que una migración agregó una columna. La validación corre en la entrada de cada job, así que una ida y vuelta a la base de datos en cada llamada costaría mucho más de lo que devuelve. El descubrimiento sigue un orden fijo, y cada barrera corre antes de que la siguiente adquiera nada: Fetcher valida el alcance de tenant antes de tocar cualquier recurso. Fetcher resuelve la conexión dentro de ese alcance. Una conexión desconocida — o una que pertenece a otro tenant — se detiene aquí como `404 Not Found`. En el camino de caché primero, un acierto devuelve de inmediato. Fetcher no construye ningún conector y no abre ninguna sesión de base de datos. Ante un fallo de caché, Fetcher resuelve el driver del tipo de datasource, abre un conector y lee el catálogo. Cierra el conector en todos los casos, con éxito o con fallo. Fetcher almacena el snapshot bajo el tenant y el nombre de configuración, y después lo devuelve. ## Qué te da la caché de esquemas *** La caché convierte una ida y vuelta a la base de datos en una búsqueda. Un acierto evita la construcción del conector y la lectura del catálogo a la vez, así que un job que valida veinte tablas en tres datasources no paga por ninguna una segunda vez dentro de la ventana. * **Clave.** Cada lectura y cada escritura tienen alcance de tenant y de nombre de configuración. Un tenant nunca ve el snapshot de otro tenant ni lo contamina. * **Vigencia.** Cinco minutos por defecto. `SCHEMA_CACHE_TTL_SECONDS` la define en el Manager. * **Almacén de respaldo.** El Manager guarda la caché en Valkey o Redis, y recurre a la memoria del proceso cuando ese almacén está inalcanzable. La caché es una optimización, y Fetcher la trata como tal. Una lectura de caché fallida degrada a un descubrimiento en vivo. Una escritura de caché fallida igual devuelve al llamador el snapshot descubierto. Ninguno de los dos fallos llega a tu respuesta. ### Correr sin caché El puerto de caché de esquema del Engine es opcional. Sin él, el descubrimiento se ejecuta en vivo desde el datasource. La validación sigue siendo correcta; paga la ida a la base de datos cada vez. Agrega una caché cuando el tráfico de validación se repite contra esquemas estables. Déjala fuera cuando el host corre extracciones ocasionales, o cuando una lectura en vivo en cada llamada es el comportamiento que quieres. ## Descubrimiento por base de datos *** | Datasource | Cómo lee Fetcher el catálogo | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | PostgreSQL | Lee `information_schema` para las tablas base y sus columnas. Recurre al esquema `public` cuando la conexión no nombra ninguno. | | MySQL | Lee `information_schema` para tablas, columnas y restricciones de clave primaria. | | Oracle | Lee las vistas de diccionario `ALL_TABLES` y `ALL_TAB_COLUMNS` para los propietarios que nombras, y las tablas del propio usuario en caso contrario. El usuario conectado es el propietario por defecto. | | SQL Server | Lee `information_schema` y recurre al esquema `dbo`. | | MongoDB | Infiere la forma. Una colección no declara ninguna. | Las lecturas de catálogo llevan un timeout de 30 segundos. ### Inferencia en MongoDB MongoDB no tiene esquema declarado, así que Fetcher construye uno en dos pasadas. Una agregación sobre la colección produce los nombres de campo. Una muestra de hasta 50 documentos da después su tipo a cada campo. La pasada de nombres de campo está acotada por el tamaño de la colección. En colecciones de hasta 10.000 documentos, la agregación procesa hasta 1.000 documentos con `$limit`; no garantiza cuáles se seleccionan. Por encima de 10.000 documentos, toma una muestra aleatoria: | Tamaño de la colección | Documentos leídos para nombres de campo | | ----------------------- | --------------------------------------- | | Hasta 1.000 | Todos | | De 1.001 a 10.000 | Hasta 1.000 con `$limit` | | De 10.001 a 100.000 | Una muestra aleatoria de 2.000 | | De 100.001 a 1.000.000 | Una muestra aleatoria de 5.000 | | Por encima de 1.000.000 | Una muestra aleatoria de 10.000 | El snapshot nombra los campos del conjunto limitado o de la muestra. La extracción genérica solo continúa cuando la planificación valida el campo seleccionado en su snapshot de esquema; no dependas de que un campo omitido del snapshot se extraiga correctamente. Cuando la agregación falla en una colección, Fetcher recurre al muestreo para esa colección y continúa con las restantes. ## Validación antes de la extracción *** `POST /v1/management/connections/validate-schema` toma el mismo mapa `mappedFields` que lleva un job de extracción. Envíalo antes de mandar el job. Una validación limpia devuelve `200` con `status: success`. Las inconsistencias de esquema devuelven `422 application/problem+json` con el código `FET-1060`; cada problema es un detalle de `errors` con ubicación, mensaje y valor estructurado. Si ninguno de los datasources solicitados se resuelve, Fetcher devuelve `400 FET-1062` de nivel superior. El Engine revisa la forma de la selección y los límites configurados antes de leer un esquema. Después resuelve cada datasource dentro del alcance del tenant y valida tablas y campos contra el snapshot con caché primero. ## Próximos pasos *** Envía un job, síguelo y lee el resultado. Registra, prueba, actualiza y elimina una conexión a un datasource. Qué hace distinto cada uno de los cinco motores de base de datos. El modelo de Fetcher en un solo lugar.