En 2024-2025 j’ai du rénover de vieux codes portant sur des processus de recherche-sélection dans une arborescence de fichiers (pour des raisons de vitesse et de standardisation) et j’ai généralisé une approche basée sur la sérialisation d’un arbre (production d’un index). Découpler la génération de l’index et son exploitation, permets également une utilisation au delà d’un système de fichiers. Au final, cela a donné un écosystème de fonctions orientées index, qui font l’objet de ce groupe de notes.
A propos des index
Dans le contexte buildez, un index correspond à la sérialisation d’un arbre, dont les nœuds et les éléments sont dotés de labels et qui peut être surchargé de données. Mais il y a plusieurs manières de sérialiser, nous pouvons, par exemple, condenser le graphe sur une ligne (un peu comme le format SMILES pour une molécule). Ce qui est une approche compliquée avec des grands arbres. Ce n’est pas non plus une sérialisation incluse dans une table, ou nous aurions dans les cellules des nœuds définis par leur identité, le nœud parent et le nœud précédent. Dans ce cas, l’intérêt est discutable, par rapport à un ‘vrai’ arbre.
La sérialisation adoptée correspond à une table, dans laquelle une colonne identifie un type d’item : élément terminal ou nœud, et une autre correspond au chemin : la succession des nœuds jusqu’à la racine. Le reste des colonnes correspond à de la donnée, qui se réfère à l’item encodé dans la ligne en cours. Le nombre des colonnes ‘données’ et leur type peuvent être différents d’un item à l’autre. C’est aussi un contexte d’opérations, nous utiliserons plutôt un index pour filtrer le contenu d’un arbre ou pour sélectionner des items sur la base des labels. Sur des arbres de 30000 éléments, c’est une approche qui encaisse bien.
Mais il y a des avantages et des inconvénients. En termes d’inconvénients, le volume des données est plus élevé. Mais pour chaque élément, nous avons accès à tous les nœuds depuis la racine … Donc un avantage en termes de recherche, simplicité de programmation, des boucles optimisables, la possibilité d’utiliser des outils et formats orientés tables ou matrices de caractères (ou Python excelle).
Version 1.4 – Mise à jour mars 2025
- Un module index pour la sérialisation d’arbres de fichiers
Pouvoir indexer un arbre de répertoire et de fichiers, c’est important pour la collecte de résultats, l’agrégation de données, la génération automatique de rapport ou de scripts … autant de ...
- Filtrage et nettoyage (regex, règles) d’index
Une fois que l’on a défini une structure de données et des formats pour des index, il faut pouvoir filtrer cette l’arborescence sérialisée. En général les besoins se limitent à ...
- Recherche de chaînes (strfind) dans un index
Il est indispensable de compléter les filtres (exclusion, regex …) avec un outil de recherche dans les entrées de l’index. Notamment, une fonction qui soit basée sur les chaines de ...
- Recherche hiérarchique dans un index
Si nous cherchons à détecter la présence de n éléments dans les entrées d’un index, ce qui peut se traduire par une recherche de chaines dans tous les nœuds qui ...
- Enrichissement d’index et interface CSVM
Il est possible de sauver le contenu d’un index filtré dans un fichier CSVM. Il s’agit d’une table (comme un fichier CSV ou Pandas) mais augmentée de métadonnées via différents ...
Actuellement l’écosystème ‘index’ est regroupé dans le sous ensemble buildez.sys avec des modules et des fonctions préfixées par le terme index_ de manière à constituer un espace de noms cohérent.
Logs
- Mise à jour en cours.