Syntaxe
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
SQLited’origine.
Utilisation d’une requête à la place d’un nom de table
À la place d’un nom de table, le deuxième argument peut être une requêteSELECT transmise telle quelle à SQLite. La structure de la table résultante est déduite du résultat de la requête. SQLite ne fournit un type déclaré que pour une colonne de résultat correspondant directement à une colonne d’une table ; pour une expression, un littéral ou un agrégat, il ne fournit rien. Un type déclaré correspondant à String (voir la correspondance des types) est utilisé tel quel. Une colonne sans type déclaré est typée d’après la classe de stockage de sa valeur dans la première ligne du résultat de la requête : une valeur INTEGER donne Int64, une valeur REAL donne Float64, et toute autre valeur (TEXT, BLOB, NULL), de même qu’un résultat vide, donne String. Un type déclaré numérique est lui aussi vérifié par rapport à cette première ligne, car SQLite fournit également un type déclaré pour un SELECT composé, issu de l’une de ses branches alors que les lignes proviennent de toutes. Il est conservé lorsque la classe de stockage de la valeur concorde avec lui (INTEGER pour un type entier, INTEGER ou REAL pour un type à virgule flottante), ainsi que lorsque la valeur est NULL ou que le résultat est vide, puisque ni l’un ni l’autre ne porte d’information de type susceptible de le contredire ; sinon, la colonne est typée d’après la classe de stockage, comme une colonne sans type déclaré. Le type déduit ne peut donc qu’être élargi, jamais ramené à une précision inférieure. La déduction d’une telle colonne lance l’exécution de la requête dans SQLite. La première ligne n’est pas représentative des suivantes : SQLite peut renvoyer une classe de stockage différente à chaque ligne (par exemple, CASE WHEN id = 1 THEN 1 ELSE 1.5 END). Une lecture fondée sur une requête est donc stricte (fail-closed) pour chaque colonne lue via un type numérique, et pas seulement pour celles sans type déclaré. Une valeur dont la classe de stockage ne correspond pas à ce type, ou qui n’y est pas représentable exactement (une cellule INTEGER valant 300 dans une colonne UInt8, une cellule REAL valant 16777217 dans une colonne Float32), fait échouer la lecture au lieu d’être convertie silencieusement. Pour lire une colonne contenant des valeurs de classes de stockage différentes, déclarez-la en String ou convertissez-la en texte dans la requête SQLite. Toute colonne déduite est Nullable. La requête peut être écrite soit sous forme de sous-requête, soit encapsulée dans la fonction query :
SELECT ... FROM (<query>) avant de l’envoyer à SQLite ; elle ne doit donc pas se terminer par un point-virgule.
Une telle table est en lecture seule : les INSERT y sont interdits. La même syntaxe est prise en charge par le table engine 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 table engine 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
Response
Voir aussi
- SQLite moteur de table
- SQLite database engine — section consacrée à la prise en charge des types de données