Simplify management of data path for multi-table schema

[marcboulle]

Objectif : simplifier l'ergonomie et la documentation sur l'usage des data paths pour le mapping multi-table

Gestion actuelle des data paths dans Khiops:

• nom du dictionnaire suivi des nom de variables
• séparé par des caractères back-quotes "`"
  • exemple pour la base Accidents
  • "Accident`Vehicles"
  • "Accident`Vehicles`Users"
  • "Accident`Place"

Proposition: utiliser le '/', comme dans les paths linux, et dans la norme JSON Patch

• data path relatif au dictionnaire d'analyse en cours, pour l'accès à ses tables internes
  • exemple pour la base Accident
  • "Vehicles"
  • "Vehicles/Users"
  • "Place"
• data path absolu, avec le nom du dictionnaire Root en tête (data root), pour les tables externes et leur composition
  • exemple de paths externes
  • "/City"
  • "/Product"
  • "/Product/features"
• cas des noms comportants des caractères '`' ou '/'
  • à mettre entre back-quotes, comme les noms de variables dans les dictionnaires
  • ne plus interdire les '`' dans les noms de variable de type Table ou Entity

Impacts et compatibilité avec les outils

Dans Khiops desktop

• les data paths sont des champs constants à l'interface donc cela ne pose aucun problème
• simplification de l'interface utilisateur: liste de saisie des Database files dans les onglets de type Train database
  • V10: Data root | Path | Dictionary | Data table file
  • V11: Data path | Dictionary | Data table file
• impact essentiellement dans la doc
• pas de problème de compatibilité ascendante

Dans KNI

• paramètrage des data paths internes: compatible avec l'existant int KNISetSecondaryHeaderLine(int hStream, const char* sDataPath, const char* sStreamSecondaryHeaderLine);
• paramètrage des data paths externes: compatible avec l'existant, en distinguant le data root, et son data path relatif int KNISetExternalTable(int hStream, const char* sDataRoot, const, char* sDataPath, const char* sDataTableFileName);
• séparateur des data path: passage de '`' à '/'
• impact documentaire
• pas de gestion de la compatibilité ascendante prévue, support aux utilisateurs existants lors du passage à la V11

Dans pykhiops

• impacts identifiés: cf. référence à une issue pykhiops ci-dessous
• gestion de la compatibilité ascendante
  • utile et nécessaire, en raison du volume de code pykhiops existant
  • non gérable de façon réaliste dans Khiops coeur (la sémantique des data paths est inconnue au niveau de la gestion des scénarios qui s'en servent comme des identifiants de lignes dans les tableaux de saisie de l'UI)
  • potentiellement plus facile à gérer côté pykhiops (les data paths sont exploités dans des méthodes connaissant leur sémantique)
  • exemple de gestion de la déprécation: à valider
  • si absence de '`' dans les data paths (cas d'un schéma en étoile): ok
  • si présence de '`' dans les data paths:
    • warning de déprécation
    • transformation de la forme V10 en forme V11

Impacts documentaires:

• guides utilisateurs, tutoriaux
• Khiops coeur et pykhiops
• site web

Impacts tests

• impacts sur tout LearningTest et les tests de la CI
  • modification des scénarios de test vers le nouveau format (scriptable assez facilement)
• en V11 d'abord
• en V10 également si back-port

Décision

• pertinence de la suggestion : ok, validé
• intégration dans une version 10.3.x ou dans la 11.0
  • en priorité V11
  • potentiellement back-port sur V10 si pas trop coûteux
  • cf. lien avec doc site sur les dictionnaires
• gestion de la déprécation de la forme actuelle : oui, à faire

Références à l'usage du séparateur '/'

• séparateur utilisé dans les paths linux
• séparateur utilisé dans les chemin json dans la norme json patch:
  • https://en.wikipedia.org/wiki/JSON_Patch
  • https://jsonpatch.com/
• séparateurs alternatifs non retenus :avec des dot ou des brackets dans les JSONPath
  • https://en.wikipedia.org/wiki/JSONPath
  • https://www.baeldung.com/guide-to-jayway-jsonpath