J’ai besoin de tracer via SQL le chemin complet d’une relation à 4 niveaux. Pour cela, je passe par la table système m_objfield.
Comment est-ce que je peux faire le lien au-delà des 2 premiers niveaux (Foreign-key simple) ?
Exemple :
J’ai un attribut d’objet personne morale (PM) qui est utilisé 4 fois dans un objet, à chaque fois pour un besoin fonctionnel différent : Un locataire PM, un investisseur PM, un propriétaire PM et un Tiers PM
Si je veux tracer le chemin complet de l’attribut ramené « Adresse complète » depuis PM Comment différencier l’adresse d’une PM locataire, de celle d’investisseur, …
En d’autres termes, comme faire le lien par exemple entre les 2 lignes suivantes : La première (18188) est le lien entre l’objet Adresse et l’objet PM Investisseur et la deuxième ligne (18189) est le lien entre l’objet Adresse et l’attribut « Adresse complète ».
Les attributs d’objet sont accessibles via le “full input” qui donne le chemin complet: fk1.fk2.fk3.myField (le “simple input” historique serait dans ce cas fk3.myField)
En fait je crois que je ne comprend pas votre question sur des requêtes SQL etc…
J’essaie de transposer dans ce qui existe au niveau logique dans Simplicité car ce que vous essayez de faire me semble juste être un mauvais workaround…
Dans un objet A si vous ramenez l’attribut b d’un objet B via un objet C selon 2 relations vous pourrez récupérer les valeurs de cet attribut sans ambiguité via le full input:
Au niveau logique tout est clair et c’est comme cela qu’on fonctionne.
Le nouveau besoin est de réussir à retrouver ce chemin fk1.fk2.fk3.myFiled au niveau de la base de données.
J’ai besoin de savoir pour chaque attribut d’objet, quel est son chemin complet ? mais via des SELECT et des jointures SQL.
Par exemple, la ligne 18188 dans mon exemple ci-dessus, me donne le lien entre l’objet l’investisseur PM (fk2) et l’objet adresse (fk3), et la ligne 18189 me donne le lien entre L’objet Adresse (fk3) et le champ que je cherche (adresse complète). Mais comment faire le lien entre ces deux lignes 18188. 18189 (fk2.fk3) ?
Je penses que je peux résumer ma demande par la question suivante :
comment je peux générer le “full input” d’un attribut d’objet via une requête SQL ?
Peut-être qu’on peut s’appeler car je comprends que le besoin est un peu spécial.
Désolé je ne comprend pas le besoin qui se cache entre les lignes de cette demande.
Vu de ma fenêtre vous essayez plus ou moins de refaire à la main ce que le moteur Simplicité fait déjà. Je n’arrive donc pas à comprendre pourquoi vous en arrivez à vouloir faire ce genre de requêtes SQL dans les tables du méta modèle. Pour moi, vous ne devriez jamais avoir à faire ce genre de choses…
Si vous activez le paramètre système LOG_SQL_USER = yes (temporairement car très verbeux dans les logs), vous verrez les requêtes générées pas Simplicité, et les alias donnés aux tables en jointure.
t.myfield : table principale
t_fk.myfield : champ ramené de 1er niveau
t_fk1_fk2_fk3.myfield : champ ramené de 3ème niveau
Le full-input se retrouve au niveau de l’alias de la table (sauf pour les vieux Oracle qui tronquent à 30 et où c’est plus compliqué de retrouver l’alias généré).
Je voudrais proposer à nos utilisateurs de faire une sorte d’extraction de données paramétrable.
Pour cela, je voudrais stocker dans un objet objParam, toutes les infos nécessaires concernant les attributs d’objets de l’objet en question.
L’utilisateur aura le choix des attributs d’objet qu’il veut inclure ou non dans l’extraction., mettre un ordre d’affichage dans l’extraction, renommer les colonnes dans l’extraction…
Ensuite, et en fonction de ce que l’utilisateur a choisi, une méthode viendra parcourir cet objParam, pour faire des get des attributs demandés, en faisant attention à utiliser la bonne get (en fonction du type d’attribut : getValue, getDouble, getInt…).
Mon besoin est donc d’ajouter dans cet objParam le chemin complet « full input » d’un attribut d’objet afin que je puisse chercher, en cas d’ambigüité, la bonne valeur si l’utilisateur le sélectionne.
Pour alimenter objParam, je passe par une requête SQL qui fait juste un SELECT dans les objets systèmes (exemple m_objfield) et qui insert toutes les infos dont j’ai besoin dans mon objet objParam.
Merci @Francois pour le paramètre système, cela m’affiche bien les alias, mais ce dont j’ai besoin, c’est une requête qui me permet de trouver le chemin complet (fk1.fk2.fk3) d’un attribut d’objet afin de le stocker dans mon objet objParam et de l’utiliser dans mon get plus tard. (getFieldValue(“fk1.fk2.fk3.myField”);
Je pense que vous pouvez répondre à ce type de besoin uniquement au niveau logique comme par exemple ce qui est proposé dans la page d’import CSV => proposez la liste des attributs de vos objets métier en bouclant via myObj.getFields() ou dans le genre (pour chaque attribut vous aurez le full input qui va biien)
En tapant en SQL dans les tables du méta modèle vous êtes forcément en train de refaire ce que le loader d’objet fait déjà pour vous en chargeant la définition des objets.
Comme je l’ai dit je ne vois pas de besoins utilisateur qui justifieraient de réinventer ce que fait le moteur Simplicité.
Depuis la V4, ce besoin me semble couvert par les préférences utilisateurs et les recherches prédéfinies couplées.
Si vous fabriquez un “gros” objet contenant tous vos champs et joins (ou objet de type “select” en lecture seule où vous pouvez spécifier des alias spécifiques par colonne en remplacement des inputs), chaque utilisateur peut enregistrer des recherches prédéfinies (via le popup de recherche) incluant les préférences utilisateur d’affichage (via le popup des préférences de Liste).
Les recherches prédéfinies incluant les préférences sont accessibles directement depuis la liste via select-box.
Cela sert aux profiles administrateur métier pour créer des vues pour export pre-cablées sur cet objet.
Et à des consommateurs pour les utiliser. Bien sur on peut avoir les 2 rôles.
