Criando uma tabela
db_path— Caminho para o arquivo SQLite que contém um banco de dados.table— Nome de uma tabela no banco de dados SQLite ou uma consulta passada ao SQLite tal como está (consulte Passando uma consulta em vez de um nome de tabela).
Passando uma consulta em vez de um nome de tabela
Em vez de um nome de tabela, o argumentotable pode ser uma consulta SELECT, repassada ao SQLite sem alterações. A estrutura da tabela é inferida a partir do resultado da consulta. O SQLite informa um tipo declarado apenas quando a coluna do resultado corresponde diretamente a uma coluna de uma tabela; para uma expressão, um literal ou uma agregação, ele não informa nada. Um tipo declarado que é mapeado para String (consulte o mapeamento de tipos) é usado sem alterações. Uma coluna sem tipo declarado tem seu tipo definido pela classe de armazenamento do seu valor na primeira linha do resultado da consulta: um valor INTEGER resulta em Int64, um valor REAL resulta em Float64, e qualquer outro valor (TEXT, BLOB, NULL), bem como um resultado vazio, resulta em String. Um tipo numérico declarado também é verificado em relação a essa primeira linha, pois o SQLite informa um tipo declarado inclusive para um SELECT composto, obtido de um de seus ramos, embora as linhas venham de todos eles. Ele é mantido quando a classe de armazenamento do valor é compatível com ele (INTEGER para um tipo inteiro, INTEGER ou REAL para um tipo de ponto flutuante), e também quando o valor é NULL ou o resultado está vazio, já que nenhum dos dois carrega informação de tipo que possa contradizê-lo; caso contrário, a coluna tem seu tipo definido pela classe de armazenamento, como ocorre com uma coluna sem tipo declarado. Portanto, o tipo inferido só pode ser ampliado, nunca reduzido. A inferência de uma coluna desse tipo inicia a execução da consulta no SQLite. A primeira linha não é representativa das demais: o SQLite pode retornar uma classe de armazenamento diferente em cada linha (por exemplo, CASE WHEN id = 1 THEN 1 ELSE 1.5 END), de modo que uma leitura baseada em consulta é fail-closed para toda coluna lida por meio de um tipo numérico - e não apenas para as que não têm tipo declarado. Um valor cuja classe de armazenamento não corresponda a esse tipo, ou que não possa ser representado exatamente nele (uma célula INTEGER com 300 em uma coluna UInt8, uma célula REAL com 16777217 em uma coluna Float32), faz a leitura falhar em vez de ser convertido silenciosamente. Para ler uma coluna com valores de classes de armazenamento diferentes, declare-a como String ou converta-a para texto na consulta do SQLite. Toda coluna inferida é Nullable. A consulta pode ser escrita como uma subconsulta ou encapsulada na função query:
SELECT ... FROM (<query>) antes de enviá-la ao SQLite, portanto ela não deve terminar com ponto e vírgula.
Essa tabela é read-only: não é permitido executar INSERT nela. A mesma sintaxe também é compatível com a função de tabela sqlite.
A forma de subconsulta
(SELECT ...) é convertida pelo ClickHouse e reserializada antes de ser enviada ao SQLite. Portanto, ela deve ser um ClickHouse SQL válido. Para passar uma sintaxe específica do SQLite que o ClickHouse não interpreta, use a forma query('...'), cujo texto é enviado ao SQLite literalmente.Qualquer WHERE, LIMIT, agregação etc. externo da consulta ClickHouse ao redor não é enviado para execução na consulta passada — ele é aplicado no ClickHouse depois que o resultado completo da consulta é recuperado. Para restringir os dados lidos do SQLite, coloque o filtro dentro da consulta passada. Com external_table_strict_query = 1, um filtro externo nas colunas da tabela é rejeitado com uma exceção, em vez de ser aplicado localmente, pois não pode ser enviado para execução na consulta passada. A verificação abrange o predicado WHERE de nível superior e cada conjunção de um AND de nível superior. Um PREWHERE nas colunas desta tabela não é um caso para essa configuração: este motor de tabela não oferece suporte a PREWHERE, e essa consulta é rejeitada com ILLEGAL_PREWHERE independentemente da configuração. A verificação é executada apenas onde um filtro poderia ser enviado para execução: quando esta tabela é a única tabela da consulta, em qualquer lado de um INNER JOIN ou no lado preservado de um join externo (o lado esquerdo de um LEFT JOIN, o lado direito de um RIGHT JOIN). No lado não preservado de um LEFT/RIGHT JOIN e em qualquer lado de um FULL JOIN, nada é enviado para execução e nada é verificado; portanto, um filtro nas colunas desta tabela é aplicado localmente após o join mesmo no modo estrito. Onde a verificação é executada, um predicado que faz referência a outras tabelas unidas na consulta ao redor não é enviado para execução e é excluído da verificação, quer faça referência apenas ao lado unido ou o misture com esta tabela em uma expressão que não seja AND (por exemplo, um OR); esse predicado mantém seu ponto de avaliação usual do ClickHouse (WHERE após o join, PREWHERE antes dele) e não é rejeitado.Suporte a tipos de dados
Ao especificar explicitamente os tipos de coluna do ClickHouse na definição da tabela, os tipos a seguir do ClickHouse podem ser convertidos a partir de colunas TEXT do SQLite:- Date, Date32
- DateTime, DateTime64
- UUID
- Enum8, Enum16
- Decimal32, Decimal64, Decimal128, Decimal256
- FixedString
- Todos os tipos inteiros (UInt8, UInt16, UInt32, UInt64, UInt128, UInt256, Int8, Int16, Int32, Int64, Int128, Int256)
- Float32, Float64
NULL do SQLite lido em uma coluna do ClickHouse explicitamente declarada como não Nullable gera a exceção CANNOT_INSERT_NULL_IN_ORDINARY_COLUMN. Declare a coluna como Nullable para ler valores NULL. Um schema inferido segue os metadados do SQLite: uma coluna é Nullable, a menos que seja declarada como NOT NULL.