Dans le cadre de l’élaboration de documentation technique/fonctionnelle de notre application nous avons besoin d’un document listant tous les champs de BDD, leur table, description du champs et éventuellement de l’objet associé.
J’ai essayé de faire ça en exportant la liste des attirbut/attirbut d’objets depuis l’IHM mais ça ne répond pas a mon besoin.
Y’a-t-il une autre fonctionnalité qui permet d’y répondre ? Est-ce faisable depuis la bdd sinon ?
(...)
Design
======
Business objects
----------------
This is the application's business model:
[OBJECTDOC:DemoSupplier]
[OBJECTDOC:DemoProduct]
[OBJECTDOC:DemoClient]
[OBJECTDOC:DemoOrder]
[OBJECTDOC:DemoContact]
State models workflows
----------------------
### Orders
Orders go thru the following state model:
Activity workflows
------------------
### Order entry
The order entry workflow has the following model:
[PROCESSDOC:DemoOrderCreate]
Profiles
--------
The application's user profiles are:
(...)
Merci pour toutes ce solutions. Ça ne répond pas au besoin initial mais ça peut être un bon complément documentaire à présenter.
Pour info, je parviens à mes fins en agrégeant les données depuis la BDD et en faisant un export csv mis en forme sous excel. Le modèle de données étant intuitif c’est assez simple à faire et à re-executer par la suite :)
J’avoue ne pas bien comprendre ce dont vous avez besoin exactement ou en tout cas ce qui manque dans ce que je vous ai indiqué (auquel cas on regardera si c’est un quelque chose qu’on peut faire évoluer)
Mais en tout état de cause si votre besoin de contenu ou de mise en forme est specifique la bonne approche c’est de vous implémenter une publication specifique (ex: la publication du catalogue produit de la démo).
S’il s’agit de générer le SQL de création de la structure des tables des objets métier de votre module ça existe aussi.
Bref indiquez nous quel est exactement votre besoin, comme toujours si ce besoin est générique et se justifie dans le cas général nous l’intégreront à la plateforme
Le besoin est d’avoir un tableau synthétiques de tous les champs utilisés dans l’application qui soit facilement exploitable (feuille de calcul).
Voilà le besoin concretement. Il me manque que le type de champ (VARCHAR, NUM etc…). J’ai repéré le champ fld_type mais je crois qu’on retrouve son libellé dans la table de traduction pour laquelle je n’ai pas encore compris le mapping :)
select fld.fld_name as "Nom du champ",
COALESCE(fld_dbname,'N/A') as "Colonne bdd",
obj.obj_name as "Nom de l'object",
obj.obj_dbtable as "Table bdd",
fld.fld_comment as "Description du champ",
fld.fld_type as "Format",
fld.fld_size as "Taille",
COALESCE(fld.fld_precision ,'Non precisé') as "Précision",
fld.fld_visible as "Visible",
fld.fld_updatable as "Modifiable",
fld.fld_required as "Requis"
from m_field fld
inner join m_module as mdl on mdl.row_id = fld.row_module_id
inner join m_objfield as obf on obf.obf_field_id = fld.row_id
inner join m_object as obj on obj.row_id = obf.obf_object_id
where mdl_name in ('module_x', 'module_y')
order by obj_name, fld_name
Le besoin est d’avoir un tableau synthétiques de tous les champs utilisés dans l’application qui soit facilement exploitable (feuille de calcul).
Ca semble extrêmement proche de la doc markdown que je vous ai indiquée et qui sort deja une vue logique complète des objets et de leurs attributs avec les commentaires saisis dans le paramétrage, ex:
Il manque juste les noms physiques (table, colonne ou autre), on peut l’ajouter facilement même si on ne voit pas forcément l’usage que ça peut avoir dans la mesure où il faut éviter d’aller taper dans la base de données mais toujours privilégier les couches logiques (API, I/O, etc.)
En tout cas ne vous embêtez surtout pas à réécrire du SQL compliqué pour refaire ce que le moteur Simplicité fait déjà.
Comme je l’ai déjà dit avec Simplicité il faut avoir le voyant qui s’allume => “si je suis en train d’écrire du SQL je fais sans doute fausse route”.
Il faut toujours s’astreindre à manipuler les objets logiques. Les cas où on a recours au SQL doivent être des cas très tordus où on sait exactement pourquoi utiliser les objets logiques n’est pas adapté.
Bref dans votre cas c’est clairement pas une requete SQL qu’il faut écrire c’est une publication qui parcoure ObjectInternal, ObjectField, Field, etc.
NB: Il y a un exemple de publication sur template qui parcours des objets/attributs/etc. dont vous pourriez vous inspirer (publication XMI):
