Crear una tabla
db_path— Ruta del archivo SQLite que contiene una base de datos.table— Nombre de una tabla en la base de datos SQLite, o una consulta que se pasa a SQLite tal cual (consulte Pasar una consulta en lugar de un nombre de tabla).
Pasar una consulta en lugar de un nombre de tabla
En lugar de un nombre de tabla, el argumentotable puede ser una consulta SELECT que se pasa a SQLite tal cual. La estructura de la tabla se infiere a partir del resultado de la consulta. SQLite solo informa de un tipo declarado para una columna del resultado que sea directamente una columna 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. A una columna sin tipo declarado se le asigna el tipo según la clase de almacenamiento de su valor en la primera fila del resultado de la consulta: un valor INTEGER da Int64, un valor REAL da Float64 y cualquier otro valor (TEXT, BLOB, NULL), así como un resultado vacío, da String. Un tipo declarado numérico también se comprueba con esa primera fila, porque SQLite informa asimismo de un tipo declarado para un SELECT compuesto, tomado de una de sus ramas, mientras que las filas proceden 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; en caso contrario, a la columna se le asigna el tipo según la clase de almacenamiento, igual que a una columna sin tipo declarado. Por 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 tipo fail-closed para todas las columnas leídas mediante un tipo numérico, y no solo para las que carecen de 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 de forma silenciosa. Para leer una columna con valores de clases de almacenamiento mixtas, 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 una 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 en ella. La función de tabla sqlite también es compatible con esta misma sintaxis.
La forma de subconsulta
(SELECT ...) es analizada por ClickHouse y se vuelve a serializar antes de enviarse a SQLite. Por lo tanto, debe ser ClickHouse SQL válido. Para pasar sintaxis específica de SQLite que ClickHouse no analiza, use la forma query('...'), cuyo texto se envía literalmente a SQLite.Cualquier WHERE, LIMIT, agregación, etc. externo de la consulta de ClickHouse circundante no se 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 tabla se rechaza con una excepción en lugar de aplicarse localmente, porque no se puede hacer pushdown de él a 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 de esta configuración: este motor de tabla no admite PREWHERE, y dicha consulta se rechaza con ILLEGAL_PREWHERE independientemente de la configuración. La comprobación se ejecuta únicamente allí donde realmente se podría hacer pushdown de un filtro: 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 circundante no se hace pushdown y queda excluido de la comprobación, tanto si hace referencia solo al lado unido como si lo mezcla con esta tabla dentro de una única expresión que no sea AND (por ejemplo, un OR); dicho predicado mantiene su punto de evaluación habitual en ClickHouse (WHERE después del join, PREWHERE antes de él) y no se rechaza.Compatibilidad con tipos de datos
Cuando se especifican explícitamente los tipos de columna de ClickHouse en la definición de la tabla, los siguientes tipos de ClickHouse se pueden analizar a partir de columnas TEXT de SQLite:- Date, Date32
- DateTime, DateTime64
- UUID
- Enum8, Enum16
- Decimal32, Decimal64, Decimal128, Decimal256
- FixedString
- Todos los tipos enteros (UInt8, UInt16, UInt32, UInt64, UInt128, UInt256, Int8, Int16, Int32, Int64, Int128, Int256)
- Float32, Float64
NULL de SQLite en una columna de ClickHouse que no sea explícitamente Nullable, se lanza la excepción CANNOT_INSERT_NULL_IN_ORDINARY_COLUMN. Para leer valores NULL, declare la columna como Nullable. Un esquema inferido se basa en los metadata de SQLite: una columna es Nullable, salvo que esté declarada como NOT NULL.