Export du modèle de données

Tags: #<Tag:0x00007f491b0f3320>

Bonjour,

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 ?

Liste des champs souhaités:

  • Nom de l’attribut
  • Nom de l’objet
  • Description de l’objet
  • Description de l’attribut
  • Type
  • Modifiable
  • Type validation
  • Liste de valeurs

Merci d’avance.

Il y a plusieurs manières de générer de la doc humainement lisible pour un module:

  1. la doc “historique” (format PDF):

  2. la doc markdown qu’on a pas encore poussé au même niveau mais qui remplacera à terme celle ci-dessus:
    image

NB: Il y a aussi une variante de celle-ci orientée API, objet par objet, dans la page API tester (/api):

1 Like

Il est aussi possible de se faire une doc “aux petits oignons” en utilisant les briques de la doc markdown, ex dans la demo:

Ex:

(...)

Design
======

Business objects
----------------

This is the application's business model:

![]([MODEL:DemoObjects])

[OBJECTDOC:DemoSupplier]

[OBJECTDOC:DemoProduct]

[OBJECTDOC:DemoClient]

[OBJECTDOC:DemoOrder]

[OBJECTDOC:DemoContact]

State models workflows
----------------------

### Orders

Orders go thru the following state model:

![]([MODEL:DemoOrderStates])

Activity workflows
------------------

### Order entry

The order entry workflow has the following model:

![]([MODEL:DemoWorkflow])

[PROCESSDOC:DemoOrderCreate]

Profiles
--------

The application's user profiles are:

![]([MODEL:DemoUsers])

(...)

Qui donne ça mis en forme en HTML: https://demo.dev.simplicite.io/ext/MDViewer?doc=DEMO

PS: En termes de modèle il est possible de générer des modèles des objets logiques mais aussi, si besoin, des tables physiques associées:


Dans le cas de la démo ça donnerait ça:

Personnellement je ne me sert jamais de cette vue physique

1 Like

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):


Si j’utilise le SQL c’est que pour moi ça va plus vite vu que c’est quelque chose que je maitrise.

Je propose qu’on aborde ce sujet lors de la revue design de cet après midi.

Bonne journée.