plugin_crm es separada.
Qué guarda un snapshot
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.
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:
1
Revisar el tenant
Fetcher valida el alcance de tenant antes de tocar cualquier recurso.
2
Resolver la conexión
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.3
Consultar la caché
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.
4
Abrir el datasource
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.
5
Escribir en caché
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_SECONDSla 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
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:
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
Jobs de extracción
Envía un job, síguelo y lee el resultado.
Conexiones
Registra, prueba, actualiza y elimina una conexión a un datasource.
Fuentes de datos
Qué hace distinto cada uno de los cinco motores de base de datos.
Conceptos centrales
El modelo de Fetcher en un solo lugar.