Actuellement l’import CSV propose à un utilisateur une interface simple pour mapper les colonnes avec un objet préexistant. Mais cela ne permet pas de créer l’objet métier.
BUILD
Il faudrait disposer d’un assistant de création d’objet métier “basique” dans un module et de son Adapter par un designer / pour l’import en production par un utilisateur final.
Sélectionner un fichier CSV ou Excel
Choisir un module + nom + table pour l’objet
Scanner et proposer les colonnes trouvées avec quelques propriétés essentielles à la génération de la table, comme :
nom logique/physique
type/longueur
clé fonctionnelle/obligatoire
méthode de transformation éventuelle (script/rhino pour transcodage, bool, format date…)
Pouvoir ignorer des colonnes
Pouvoir ajouter des colonnes = champ calculé avec les colonnes connues (ex script/rhino pour couper une colonne en N attributs)
Génération de l’objet (+ énumérés) et de l’adapter qui exécutera les transformations à l’import.
L’objet est à peaufiner pour compléter le paramétrage
A voir si on peut sous-traiter à une IA ou si ça restera un scan élémentaire/prédictif.
Au runtime, une fois l’objet livré, il suffira de passer par l’import par l’Adapter dédié.
En cas d’évolution du fichier source, l’idéal sera de pouvoir rejouer le process de génération sans tout refaire (extraire les règles depuis l’adapter “codé”, ou mieux modéliser les champs/règles du fichier directement sur l’adapter via une relation NN AdapterField), sinon il faudra au moins pouvoir maintenir l’objet et l’adapter “à la main”.
En première approche la retranscription est fidèle.
Il faut garder quelques chose de simple pour automatiser ce qui peut l’être sans ajouter une complexité qui pourrait être gérée par une petite retouche de l’objet (cette fonction ne doit pas s’occuper des ordres de tri, des liaisons entre tables, etc).
Il serait cependant utile d’identifier une colonne comme portant un champ énuméré, de proposer la création de la liste associée issue du scan de la table.
Comme il s’agit d’un besoin ponctuel dans la vie d’un projet, il est en effet peut-être préférable de traiter le besoin au travers d’un module.
L’option IA peut être pertinente, mais ne pas oublier ceux qui sont on-premise sur un réseau isolé. Pour ceux-là une fonction autonome est préférable.
Bien mettre en évidence que cette fonction est complémentaire de la nouvelle fonction 6.2 de détachement de colonnes (et de dédoublonnement déjà existante) pour la création d’un nouvel objet métier.
Oui c’est bien l’idée. Il faut générer un objet avec uniquement les choses nécessaires et suffisantes pour l’import/persistance. Et comme toute génération elle sera injective, on ne peut pas garantir de bijection avec la source si les modifications avales/manuelles deviennent incompatibles. Ca reste de la génération de modèle/code.
Tout à fait, c’est facile de créer un ENUM via un “select distinct” des valeurs transformées en codes renormalisés (sans accent, ni espace…) avec chaque valeur traduite dans une langue.
Oui à voir comme un utilitaire de build, surtout si la “source” de données est une interface : un fichier ou une requete distante… c’est le même besoin d’import à partir de données plates sans trop de métadata.