La recherche full-text dans QoreDB : scanner toutes les tables d'une base

Quand on travaille sur une base qu'on ne connaît pas encore bien, ou quand on cherche une valeur précise sans savoir dans quelle table elle se trouve, la recherche manuelle table par table est lente et frustrante. C'est un besoin courant chez les développeurs qui déboguent en production ou qui reprennent un projet existant.

QoreDB intègre une recherche full-text globale qui scanne toutes les tables d'une base connectée pour trouver une chaîne. Le mécanisme repose sur des stratégies par driver, une exécution parallèle avec timeouts, et une détection automatique des index full-text existants.

Une stratégie de recherche par moteur

Chaque moteur de base de données a ses propres capacités en matière de recherche textuelle. PostgreSQL expose les tsvector et les index GIN/GiST. MySQL propose les index FULLTEXT. MongoDB offre les index $text et le pattern matching via $regex. SQLite, de son côté, peut utiliser les extensions FTS si elles sont activées.

Plutôt que d'imposer une abstraction unique, QoreDB définit un trait Rust FulltextSearchStrategy que chaque driver implémente. Ce trait expose quatre responsabilités : détecter les index full-text sur une table, analyser les colonnes textuelles disponibles, construire la requête de recherche optimale, et fournir un fallback basé sur LIKE ou ILIKE quand aucun index natif n'est disponible.

Sur PostgreSQL, si la table dispose d'un index GIN sur une colonne tsvector, QoreDB génère une requête utilisant to_tsquery avec le préfixe :* pour le matching partiel. Sinon, il construit une série de conditions ILIKE sur les colonnes textuelles. Sur MySQL, la logique est identique : MATCH...AGAINST en mode boolean si un index FULLTEXT existe, LIKE sinon. Sur MongoDB, la recherche passe par un $text si un index text est présent, ou par un $regex sur chaque champ string du document.

Exécution parallèle et timeouts

Scanner toutes les tables d'une base peut être coûteux. Une base avec 200 tables et des millions de lignes ne peut pas être parcourue séquentiellement sans bloquer l'interface. QoreDB utilise le runtime tokio pour lancer les recherches en parallèle, par lots de 5 tables simultanées (configurable). Chaque recherche sur une table individuelle est encadrée par un timeout de 5 secondes. Si une table ne répond pas dans ce délai, elle est marquée en timeout et la recherche continue sur les autres.

Les résultats arrivent progressivement grâce au mécanisme d'événements Tauri. Le frontend reçoit des événements de progression indiquant combien de tables ont été scannées, combien de résultats ont été trouvés, et quelle table est en cours de traitement. L'utilisateur voit les résultats apparaître au fur et à mesure, sans attendre la fin du scan complet.

Détection et cache des capacités

Avant de lancer la recherche sur une table, QoreDB exécute une requête de détection pour identifier les index full-text présents. Sur PostgreSQL, il interroge pg_class, pg_index et pg_am pour trouver les index GIN ou GiST associés à des colonnes tsvector. Sur MySQL, il lit les métadonnées INFORMATION_SCHEMA pour repérer les index FULLTEXT.

Ces détections sont mises en cache pendant 5 minutes dans un CapabilityCache global, protégé par un RwLock asynchrone. Tant que le cache est valide, les recherches suivantes sur la même table réutilisent la stratégie déjà calculée sans réinterroger les métadonnées. Ce cache est invalidé automatiquement après expiration ou quand il dépasse 1000 entrées.

Filtrage intelligent des colonnes

Pour éviter de scanner des colonnes où une recherche textuelle n'a pas de sens, QoreDB filtre les colonnes par type. Seules les colonnes dont le type contient char, text, varchar, json, xml, uuid ou enum sont incluses dans le scan. Les colonnes numériques, binaires ou de date sont exclues. Les tables système (pg_catalog, information_schema, mysql, sys) et les tables dont le nom commence par pg_ ou _ sont également ignorées.

SQLite fait exception : comme ses types sont flexibles et que n'importe quelle colonne peut contenir du texte, toutes les colonnes sont incluses dans la recherche. C'est un choix pragmatique adapté à la réalité du moteur.

L'interface de recherche

Côté frontend, la recherche full-text s'ouvre dans un panneau modal dédié. L'input est débounced à 300 ms pour éviter de surcharger le backend pendant la frappe. Les résultats sont groupés par table, avec un compteur de matches par groupe. Chaque résultat affiche le nom de la colonne, un aperçu de la valeur trouvée avec surlignage du terme recherché, et un extrait des autres colonnes de la ligne pour donner du contexte.

Un clic sur un résultat ouvre directement la table concernée avec un filtre pré-rempli sur la colonne et la valeur recherchée. La barre de statistiques en bas du panneau indique le nombre total de correspondances, le nombre de tables scannées et le temps d'exécution. Si les résultats sont tronqués (au-delà de 100 résultats par défaut), un indicateur visuel le signale.

Un switch permet d'activer la recherche sensible à la casse, qui modifie à la fois la requête backend (LIKE au lieu de ILIKE sur PostgreSQL, par exemple) et le surlignage côté frontend.

En pratique

Sur une base PostgreSQL de 80 tables, une recherche full-text typique prend entre 1 et 3 secondes. Les tables avec des index GIN répondent en quelques millisecondes, les tables sans index sont plus lentes mais restent dans le budget du timeout. Les résultats les plus pertinents arrivent en premier grâce au parallélisme : les tables rapides remontent leurs résultats avant que les tables lentes aient terminé.

La recherche est volontairement bornée : 10 résultats maximum par table, 100 au total, 5 secondes de timeout par table. Ces limites sont là pour garantir que l'interface reste réactive, même sur des bases volumineuses. Si un utilisateur veut explorer plus en profondeur, le clic sur un résultat le redirige vers la table avec le filtre appliqué, où il peut paginer normalement.

La recherche full-text de QoreDB est conçue comme un outil d'exploration rapide, pas comme un moteur de recherche exhaustif. Elle tire parti des capacités natives de chaque moteur quand elles existent, et se rabat sur du pattern matching simple quand elles n'existent pas. Le résultat est un outil qui fonctionne partout, sur tous les drivers supportés, avec un coût prévisible et une interface claire.