Créez une clause WHERE SQL paramétrée depuis des filtres

Chaque nom de champ est délimité comme identifiant SQL, segment par segment pour les noms qualifiés, tandis que les valeurs restent hors du texte SQL. Les filtres conservent leur ordre initial et sont reliés par AND. Le résultat est donc prévisible pour les générateurs de requêtes, outils d’administration, écrans de rapport et endpoints qui reçoivent déjà les filtres sous forme de données.

Construisez la structure SQL sans concaténer les valeurs

Les écrans de recherche dynamique partent souvent d’enregistrements d’apparence anodine : un champ, un opérateur et une valeur. Le danger apparaît lorsque ces données deviennent du SQL par insertion directe de la valeur dans une chaîne. Ce générateur sépare la structure et les données. Il renvoie une clause WHERE SQL paramétrée avec des paramètres positionnels de style PostgreSQL, tels que $1 et $2, ainsi qu’un tableau params dans l’ordre correspondant exact. Intégrez la clause à une instruction SELECT, UPDATE ou DELETE plus large, puis transmettez params à un pilote compatible. Le générateur n’exécute aucune requête, ne se connecte à aucune base, n’inspecte aucun schéma et ne décide pas quelles colonnes l’appelant peut utiliser. Votre application doit conserver une liste d’autorisation si les utilisateurs influencent les champs. La délimitation empêche la ponctuation et les mots réservés de casser la syntaxe, mais l’autorisation reste du ressort de l’application. Les filtres étant reliés par AND dans l’ordre reçu, la sortie reste stable et facile à journaliser, comparer ou combiner à un préfixe de requête fixe.

Maîtrisez les opérateurs, paramètres et tests de nullité

Les opérateurs pris en charge couvrent l’égalité, l’inégalité, les comparaisons d’ordre, LIKE, NOT LIKE, IN, NOT IN, IS NULL et IS NOT NULL. Le texte de l’opérateur passe en majuscules et les espaces répétés sont réduits : une saisie comme « not like » produit donc un SQL canonique. Chaque comparaison ordinaire consomme un paramètre. IN et NOT IN exigent un tableau non vide et le développent en un paramètre par élément tout en préservant l’ordre. Les tests de nullité ne consomment aucun paramètre et ne nécessitent aucune valeur, car leur grammaire SQL ne contient pas de marqueur. Toute valeur manquante pour un autre opérateur est refusée plutôt que de produire un SQL incomplet. Les valeurs scalaires JSON sont acceptées, notamment les chaînes, nombres, booléens et null ; les tableaux sont réservés aux deux opérateurs de liste. La sortie emploie volontairement des paramètres numérotés précédés d’un dollar, adaptés à PostgreSQL et aux bibliothèques compatibles. Si votre pilote utilise des points d’interrogation ou des noms, adaptez la syntaxe sans modifier l’ordre des valeurs renvoyées.

Délimitez les identifiants et validez la politique applicative

Chaque champ est considéré comme un identifiant éventuellement qualifié. Un nom tel que users.created_at devient deux segments délimités séparément, tandis qu’un guillemet double interne est échappé par doublement, conformément aux règles SQL usuelles. Les noms vides et les segments vides entre deux points sont refusés. Ce traitement empêche de confondre un champ avec de la syntaxe SQL non délimitée, sans prétendre que tous les moteurs suivent exactement les mêmes conventions. Vérifiez la compatibilité avec votre base cible, surtout si elle n’emploie pas les guillemets doubles pour les identifiants. Par ailleurs, l’échappement n’accorde aucun droit. Si un appelant externe choisit les champs, associez les clés publiques à un ensemble explicite de colonnes avant d’appeler le générateur. Appliquez aussi vos règles métier aux opérateurs : un endpoint de rapport peut autoriser égalité et intervalles tout en refusant les motifs, même si LIKE est disponible. Tout opérateur SQL inconnu déclenche une erreur de saisie claire. Cette capacité est déterministe, n’effectue aucune requête réseau et renvoie uniquement la clause et ses paramètres.