Sintaxis
Argumentos
db_path— Ruta de acceso a un archivo con una base de datos SQLite. String.table_name— Nombre de una tabla en la base de datos SQLite, o una consulta que se pasa a SQLite tal cual (consulta Pasar una consulta en lugar de un nombre de tabla). String.
Valor devuelto
- Un objeto de tipo tabla con las mismas columnas que la tabla original de
SQLite.
Pasar una consulta en lugar de un nombre de tabla
En lugar de un nombre de tabla, el segundo argumento puede ser una consultaSELECT que se pasa a SQLite tal cual. La estructura de la tabla resultante se infiere a partir del resultado de la consulta. SQLite solo informa de un tipo declarado para las columnas del resultado que son columnas directas de una tabla; para una expresión, un literal o una agregación no informa de nada. Un tipo declarado que se corresponde con String (consulte la correspondencia de tipos) se utiliza tal cual. Una columna sin tipo declarado recibe su tipo según la clase de almacenamiento de su valor en la primera fila del resultado de la consulta: un valor INTEGER produce Int64, un valor REAL produce Float64, y cualquier otro valor (TEXT, BLOB, NULL), así como un resultado vacío, produce String. Un tipo declarado numérico también se comprueba con esa primera fila, porque SQLite también informa de un tipo declarado para un SELECT compuesto, tomado de una de sus ramas, aunque las filas procedan de todas ellas. Se conserva cuando la clase de almacenamiento del valor concuerda con él (INTEGER para un tipo entero, INTEGER o REAL para un tipo de coma flotante), y también cuando el valor es NULL o el resultado está vacío, ya que ninguno de los dos aporta información de tipo que pueda contradecirlo; de lo contrario, la columna recibe su tipo según la clase de almacenamiento, igual que una columna sin tipo declarado. Por lo tanto, el tipo inferido solo puede ampliarse, nunca reducirse. Inferir una columna de este tipo inicia la ejecución de la consulta en SQLite. La primera fila no es representativa del resto: SQLite puede devolver una clase de almacenamiento distinta en cada fila (por ejemplo, CASE WHEN id = 1 THEN 1 ELSE 1.5 END), por lo que una lectura basada en una consulta es de cierre ante fallos (fail-closed) para todas las columnas leídas mediante un tipo numérico, no solo para las que no tienen tipo declarado. Si un valor tiene una clase de almacenamiento que no coincide con ese tipo, o no puede representarse exactamente en él (una celda INTEGER con 300 en una columna UInt8, una celda REAL con 16777217 en una columna Float32), la lectura falla en lugar de convertirlo silenciosamente. Para leer una columna con valores de distintas clases de almacenamiento, declárela como String o conviértala a texto en la consulta de SQLite. Todas las columnas inferidas son Nullable. La consulta puede escribirse como subconsulta o envolverse en la función query:
SELECT ... FROM (<query>) antes de enviarla a SQLite, por lo que no debe terminar en punto y coma.
Una tabla de este tipo es de solo lectura: no se permite ejecutar INSERT sobre ella. El motor de tabla SQLite admite la misma sintaxis.
La forma de subconsulta
(SELECT ...) la analiza ClickHouse y vuelve a serializarla antes de enviarla a SQLite. Por lo tanto, debe ser SQL de ClickHouse válido. Para pasar sintaxis específica de SQLite que ClickHouse no analiza, use la forma query('...'), cuyo texto se envía a SQLite literalmente.Cualquier WHERE, LIMIT, agregación, etc. externo de la consulta de ClickHouse que la rodea no hace pushdown en la consulta pasada; se aplica en ClickHouse después de recuperar el resultado completo de la consulta. Para restringir los datos leídos desde SQLite, coloque el filtro dentro de la consulta pasada. Con external_table_strict_query = 1 un filtro externo sobre las columnas de la table function se rechaza con una excepción en lugar de aplicarse localmente, porque no se puede hacer pushdown de él en la consulta pasada. La comprobación abarca el predicado WHERE de nivel superior y cada conjunción de un AND de nivel superior. Un PREWHERE sobre las columnas de esta tabla no es un caso para esta configuración: este motor de tabla no admite PREWHERE, y una consulta así se rechaza con ILLEGAL_PREWHERE independientemente de la configuración. La comprobación se ejecuta solo allí donde un filtro podría hacer pushdown: cuando esta tabla es la única tabla de la consulta, en cualquiera de los lados de un INNER JOIN, o en el lado preservado de un outer join (el lado izquierdo de un LEFT JOIN, el lado derecho de un RIGHT JOIN). En el lado no preservado de un LEFT/RIGHT JOIN y en cualquiera de los lados de un FULL JOIN no se hace pushdown de nada ni se comprueba nada, por lo que un filtro sobre las columnas de esta tabla se aplica localmente después del join incluso en modo estricto. Allí donde la comprobación se ejecuta, un predicado que hace referencia a otras tablas unidas en la consulta que la rodea no hace pushdown y queda excluido de la comprobación, tanto si hace referencia únicamente al lado unido como si lo mezcla con esta tabla dentro de una misma expresión que no sea AND (por ejemplo, un OR); tal predicado conserva su punto de evaluación habitual en ClickHouse (WHERE después del join, PREWHERE antes de él) y no se rechaza.Ejemplo
Query
Response
Relacionado
- Motor de tabla de SQLite
- Motor de base de datos SQLite — sección sobre compatibilidad con tipos de datos