Partie 11 : Expressions Logiques SQL
Les articles de la série
- Partie 1 : Construire le REPL
- Partie 2 : Sérialisation des données
- Partie 3 : Database
- Partie 4 : Tables
- Partie 5 : Parser les commandes, création de la boîte à outils
- Partie 6 : Parser les commandes SQL
- Partie 7 : Tuples de données
- Partie 8 : Contraindre les données via un schéma
- Partie 9 : Découper le stockage des tables en pages
- Partie 10 : Clefs primaires
- Partie 11 : Expressions Logiques SQL
- Partie 12 : Scans et filtrage
- Partie 13 : UTF-8 et caractères échappés
- Partie 14 : Attributs nullifiables
- Partie 15 : Index secondaires
Bonjour à toutes et tous 😃
L'introduction du concept de clef primaire permet de récupérer une entrée dans la base de données sans devoir scanner tous les éléments un par un jusqu'à trouver le bon.
C'est pas mal du tout, mais un peu limité.
Généralement les requêtes sont un peu plus complexes et utiles.
Si l'on reprend la métaphore de notre annuaire téléphonique, c'est comme si pour trouver quelqu'un, vous n'avez que deux choix: soit vous chercher dans toutes les pages à la recherche du bon nom soit vous connaissez déjà le numéro de page et c'est nettement plus simple. Ça c'est le fonctionnement de l'index primaire et du full-scan.
Maintenant, imaginons que l'on veuille récupérer les numéros de tous les hommes habitant dans la ville "X".
Dans la vraie vie, pour ceux qui n'ont jamais vu un, si si ça doit exister maintenant 😅. Les entrées sont décomposé en section pour chaque ville et trié par ordre alphabétique.
Nous pouvons modéliser notre annuaire au travers d'une table PhoneBook
.
TEXT(50) PRIMARY KEY, city TEXT(50), phone_number TEXT(50), gender TEXT(1));
(name
Notre requête dans l'annuaire ne peut pas être par clef primaire.
Il faut connaître les noms des personnes pour les trouver.
SELECT * FROM PhoneBook WHERE name='Alexandre Adams'
SELECT * FROM PhoneBook WHERE name='Amandine Agostini'
SELECT * FROM PhoneBook WHERE name='Arthur Almeida'
SELECT * FROM PhoneBook WHERE name='Anaïs Aubert'
...
Ce n'est pas très pratique... 😑
La vraie requête que l'on veut c'est:
SELECT * FROM PhoneBook WHERE city = 'X' AND gender = 'H';
Cette partie de la requête, nous allons l'appeler "expression".
city = 'X' AND gender = 'H'
Je vous propose de mettre en place le parse de cette expression dans cette nouvelle partie de notre épopée.
Grammaire
Avant de partir en bataille avec notre parser, nous allons en définir les contours.Expression logique
Expression ::= ColumnExpression | Expression LogicalOperator Expression
ColumnExpression ::= Column BinaryOperator LiteralValue
LogicalOperator ::= 'AND' | 'OR'
BinaryOperator ::= '=' | '!=' | '>' | '>=' | '<' | '<='
Column ::= [A-Za-z_]+
LiteralValue ::= LiteralString | LiteralInteger
LiteralString ::= "'" [^']+ "'"
LiteralInteger ::= [0-9]+
Notre grammaire se complexifie. Nous avons tout une série de nouveaux tokens à rajouter.
AND
OR
!=
=
>
<
>=
<=
Nous avons introduit également le concept d'expression de colonne ColumnExpression
.
On associe un identifiant de colonne et une valeur comparé par un opérateur binaire BinaryOperator
.
id > 12
name != 'Max'
Mais nous avons également la possibilité de d'associer deux ColumnExpression
via un LogicalOperator
.
Et on peut le faire autant que l'on veut.
id > 12 AND name != 'Max' OR data = 'true'
Ajout des tokens
On rajoute nos différents tokens
On y associe un Matcher
Ainsi que la taille des tokens
Parsing de l'expression
Comme la grammaire le laisse supposer, parser une Expression est plus complexe que parser les embryon de commandes que nous avons déjà dans notre arsenal.
La principal difficulté étant qu'une Expression est récursivement une Expression.
Mais avant de nous attaquer au plat de resistance et de l'avoir sur l'estomac par indigestion. Nous allons décomposer le problèmes en sous-problèmes et recomposer le puzzle.
Recognizer
On avait déjà un Acceptor qui permettait d'avoir des alternatives de visiteurs, le Forecaster qui donnait le choix de forecast de groupe de token dans le futur.
Il nous manquait la possiblité de choisir une collection de tokens à reconnaître.
Avec le Recognizer
c'est chose faite !
Même principe que pour les deux autres, on lui fourni une liste de choses à reconnaître et il tente de reconnaître le token, s'il n'y arrive pas, il passe au suivant, sinon il s'arrête et propage le token reconnu.
En sorti de méthode finish
on obtient alors une Option du token.
Binary Operator
La première chose que l'on va vouloir reconnaître c'est nos opérateurs binaires.
!=
=
>
<
>=
<=
Nous avons besoin d'une énumération pour modéliser ces opérateurs
Ainsi que d'un TryFrom qui va permettre de passer du token reconnu à l'opérateur.
On peut alors reconnaître notre opérateur.
ColumnExpression
On peut désormais représenter notre ColumnExpression
Que l'on peut alors visiter.
Ce qui donne:
Parfait! On peut maintenant parser une ColumnExpression 🤩
Opérateur logique
On fait de même pour les tokens:
- AND
- OR
Permettant de reconnaître les opérateur logique.
Expression
Notre expression est une suite de ColumnExpression séparé par de LogicalOperator.
Lorsque l'on a une expression du genre:
id > 12 AND name = 'toto'
Cela donne une expression du genre
ColumnExpression LogicalOperator ColumnExpression
Mais si on a quelque chose commen
id > 12 AND name = 'toto' AND gender = 'M'
Cela donne l'expression suivante
ColumnExpression LogicalOperator ColumnExpression LogicalOperator ColumnExpression
Sauf que l'opérateur logique n'a que deux paramètres:
- un à gauche
lhs
- un à droite
rhs
Si on redécoupe
ColumnExpression LogicalOperator [ ColumnExpression LogicalOperator ColumnExpression ]
On réduit encore
ColumnExpression LogicalOperator LogicalExpression
Et si l'on veut que le système soit totalement récursif, notre expression doit se réduire en
LogicalExpression
On en déduit deux choses.
Nous avons besoin d'une énumération qui permette de faire une union entre la ColumnExpression et la LogicalExpression
On la visite
LogicalExpression
On peut alors en définir le LogicalExpression
Le boxing
Box<Expression>
est obligatoire car Expression peut contenir une LogicalExpression qui contient lui même une Expression, etc ...Cela conduit à une taille infinie.
Ça la stack n'aime pas du tout, la heap n'a pas ce problème.
On en défini également un constructeur
Et finalement un visiteur
Test de parse
On peut finalement parser nos Expressions
Expression simple
D'abord une simple comparaison
Expression logique
Puis une utilisant un connecteur logique
Expression logiques composites
Puis un chaînage de plusieurs expressions
Et voilà ! 🤩
Nous sommes capables de parser des expressions logiques SQL. 😍😍😍
Pas toutes biensûr, mais c'est un début.
En tout cas ça sera suffisant pour la suite de mes explications.
Conclusion
Oui, c'était encore un épisode de parsing, mais que voulez vous, il faut bien des outils pour bâtir des choses, et le parsing est nécessaire pour nous ouvir le champ des possibles. 😎
Dans la prochaine partie nous utiliserons nos expressions pour requêter notre base données sur autre chose que la clef primaire.
Merci de votre lecture ❤️
Vous pouvez trouver le code la partie ici et le diff là.
Ce travail est sous licence CC BY-NC-SA 4.0.