Lo que comparten todos los motores
Define el motor con el
type de la conexión, en mayúsculas: POSTGRESQL, MYSQL, ORACLE, SQL_SERVER, MONGODB. La validación de la solicitud compara exactamente esas cinco cadenas, así que cualquier otra capitalización falla con 400.
Estos límites son iguales en todos lados:
Los cuatro motores relacionales comparten un mismo perfil de pool de conexiones: 25 conexiones abiertas, 10 conexiones inactivas, una vida de conexión de 5 minutos y un timeout de inactividad de 1 minuto. MongoDB usa un pool de 100 como máximo y 10 como mínimo, con el mismo timeout de inactividad de 1 minuto.
La proyección de campos también funciona igual. Una lista de nombres de campos selecciona esos campos. La entrada única
["*"] los selecciona todos.
PostgreSQL
Schemas. PostgreSQL es el motor multi-schema más completo dentro de Fetcher. El descubrimiento lee
information_schema para los schemas que nombra tu job, y cae de vuelta a public cuando el job no nombra ninguno.
Nombres de tabla. Una tabla fuera de public vuelve calificada con schema, como accounting.invoices. Una tabla dentro de public vuelve sin prefijo, como users. Escribe el nombre de la misma forma en mappedFields.
Claves de filtro. Una clave de filtro se resuelve en tres formas: el nombre exacto, el nombre sin su prefijo de schema y el nombre con public añadido. Por eso transactions y public.transactions llegan a la misma tabla.
Columnas JSON. El driver devuelve las columnas JSON y JSONB como bytes crudos. Fetcher intenta leer cada valor como objeto JSON, luego como arreglo JSON, luego como cadena JSON. El valor parseado va al resultado. Un valor que no coincide con ninguna de las tres formas queda crudo, y Fetcher registra una advertencia.
MySQL
Sin lista de schemas. MySQL es el único motor relacional sin dimensión de schema dentro de Fetcher. La base de datos conectada es el namespace. El descubrimiento lee
information_schema para las tablas, columnas y claves primarias de esa base.
Nombres de tabla. Escribe los nombres de tabla sin prefijo. Un prefijo de schema no tiene contra qué resolverse.
Claves de filtro. Una clave de filtro debe coincidir con el nombre de la tabla exactamente como lo escribiste bajo mappedFields.
Columnas JSON. Fetcher aplica a los valores en bytes la misma lectura JSON de tres pasos que en PostgreSQL: objeto, luego arreglo, luego cadena.
Oracle
Owners, no schemas. Oracle llama owner al namespace, y Fetcher trata al owner como el schema. Cuando tu job nombra owners, el descubrimiento lee
all_tables, all_tab_columns y all_cons_columns restringido a esos owners. Cuando no nombra ninguno, el descubrimiento cae de vuelta a user_tables y user_cons_columns, que cubren solo al usuario conectado.
El owner por defecto es el usuario con el que autentica la conexión.
Nombres de tabla. Una tabla del usuario conectado vuelve sin prefijo. Cualquier otra tabla vuelve calificada con owner, como OWNER.TABLE. Fetcher compara los nombres de owner sin distinguir mayúsculas, y pasa el owner a mayúsculas antes de consultar el catálogo de Oracle. Fetcher también pasa a mayúsculas los nombres de tabla y de columna en el esquema que reporta de vuelta, y las filas extraídas usan esos nombres de columna en mayúsculas como claves. Puedes escribir un job en mayúsculas o en minúsculas, porque Fetcher pasa a mayúsculas los nombres de tu solicitud de la misma forma. Lee los resultados por la clave en mayúsculas.
Claves de filtro. Oracle compara una clave de filtro de forma exacta. No hay respaldo por prefijo.
Columnas JSON. Los valores en bytes pasan por la misma lectura JSON de tres pasos.
SQL Server
Schemas. SQL Server es multi-schema, con
dbo como schema por defecto. El descubrimiento lee information_schema.tables para los schemas que nombra tu job, y se restringe a dbo cuando el job no nombra ninguno.
Nombres de tabla. Una tabla fuera de dbo vuelve calificada con schema, como accounting.invoices. Una tabla dentro de dbo vuelve sin prefijo. Es la misma regla que PostgreSQL aplica a public.
Claves de filtro. SQL Server resuelve una clave de filtro en las mismas tres formas que PostgreSQL, con dbo como prefijo por defecto.
Columnas JSON. Los valores en bytes pasan por la misma lectura JSON de tres pasos.
MongoDB
Colecciones, no tablas. MongoDB no tiene namespace de schema. Escribe los nombres de colección sin prefijo. Una clave de filtro debe coincidir con el nombre de la colección de forma exacta. Esquema inferido. Los documentos no traen un esquema declarado, así que Fetcher construye uno en dos pasadas sobre cada colección:
- Un pipeline de agregación reúne el conjunto completo de nombres de campo.
- Una muestra de hasta 50 documentos infiere el tipo de cada campo. Un campo que la muestra nunca ve conserva el tipo
unknown.
$sample, con un tamaño que apunta a 95% de confianza con 5% de margen de error:
Por eso un esquema inferido es una muestra fuerte, no una garantía. Un campo que existe en unos pocos documentos de una colección muy grande puede quedar fuera. Si la agregación falla en una colección, Fetcher registra una advertencia y cae de vuelta al muestreo en lugar de hacer fallar el descubrimiento.
Filtros. MongoDB toma los mismos diez operadores, traducidos a operadores de consulta. Un patrón
like se vuelve una expresión regular que ignora mayúsculas y minúsculas. MongoDB es además el único motor que no ejecuta la comprobación de UUID sobre los nombres de campo que parecen identificadores. Consulta Filtros.
Opciones de conexión. Un datasource interno pasa opciones del driver como authSource y directConnection mediante DATASOURCE_{NAME}_OPTIONS.
Próximos pasos
Jobs de extracción
Cómo un job nombra datasources, tablas, schemas y campos.
Filtros
Los diez operadores de filtro y la forma de valor que toma cada uno.