sqlite

Permet d’exécuter des requêtes sur des données stockées dans une base de données SQLite.

Permet d’exécuter des requêtes sur des données stockées dans une base de données SQLite.

​

Syntaxe

sqlite('db_path', 'table_name')

​

Arguments

• db_path — Chemin d’accès à un fichier contenant une base de données SQLite. String.
• table_name — Nom d’une table de la base de données SQLite, ou d’une requête transmise à SQLite telle quelle (voir Transmettre une requête au lieu d’un nom de table). String.

​

Valeur renvoyée

• Un objet de table avec les mêmes colonnes que la table SQLite d’origine.

​

Utilisation d’une requête à la place d’un nom de table

Au lieu d’un nom de table, le deuxième argument peut être une requête SELECT transmise telle quelle à SQLite. La structure de la table obtenue est déduite du résultat de la requête. La requête peut être écrite soit sous forme de sous-requête, soit encapsulée dans la fonction query :

SELECT * FROM sqlite('sqlite.db', (SELECT col1, col2 FROM table1 WHERE col2 > 1));
SELECT * FROM sqlite('sqlite.db', query('SELECT col1, col2 FROM table1 WHERE col2 > 1'));

Une telle table est en lecture seule : INSERT n’y est pas autorisé. La même syntaxe est prise en charge par le moteur de table SQLite.

La forme de sous-requête (SELECT ...) est analysée par ClickHouse, puis re-sérialisée avant d’être envoyée à SQLite. Elle doit donc être valide en ClickHouse SQL. Pour transmettre une syntaxe propre à SQLite que ClickHouse n’analyse pas, utilisez la forme query('...'), dont le texte est envoyé tel quel à SQLite.

Les clauses externes WHERE, LIMIT, les agrégations, etc., de la requête ClickHouse englobante ne sont pas répercutées dans la requête transmise — elles sont appliquées dans ClickHouse après la récupération du résultat complet de la requête. Pour limiter les données lues depuis SQLite, placez le filtre dans la requête transmise. Avec external_table_strict_query = 1, un filtre externe portant sur les colonnes de la fonction de table provoque une exception au lieu d’être appliqué localement, car il ne peut pas être répercuté dans la requête transmise. La vérification porte sur le prédicat WHERE de premier niveau et sur chaque conjonction d’un AND de premier niveau. Un PREWHERE sur les colonnes de cette table ne relève pas de ce paramètre : ce moteur de table ne prend pas en charge PREWHERE, et une telle requête est rejetée avec ILLEGAL_PREWHERE quel que soit le paramètre. La vérification n’a lieu que là où un filtre pourrait effectivement être répercuté : lorsque cette table est la seule table de la requête, de part et d’autre d’un INNER JOIN, ou du côté préservé d’un outer join (le côté gauche d’un LEFT JOIN, le côté droit d’un RIGHT JOIN). Du côté non préservé d’un LEFT/RIGHT JOIN et de part et d’autre d’un FULL JOIN, rien n’est répercuté et rien n’est vérifié : un filtre sur les colonnes de cette table est donc appliqué localement après le join, même en mode strict. Là où la vérification s’applique, un prédicat qui référence d’autres tables jointes dans la requête englobante n’est pas répercuté et est exclu de la vérification, qu’il référence uniquement le côté joint ou qu’il le combine avec cette table au sein d’une même expression non-AND (par exemple un OR) ; un tel prédicat conserve son point d’évaluation ClickHouse habituel (WHERE après le join, PREWHERE avant) et n’est pas rejeté.

​

Exemple

Query

SELECT * FROM sqlite('sqlite.db', 'table1') ORDER BY col2;

Response

┌─col1──┬─col2─┐
│ line1 │    1 │
│ line2 │    2 │
│ line3 │    3 │
└───────┴──────┘

​

Voir aussi

• SQLite moteur de table
• SQLite database engine — section consacrée à la prise en charge des types de données