Discussion :

[ced]

Bonjour,

J'ai constaté que Looping n'arrivait pas à "traduire" les types de données d'un script DDL de PostgreSQL.
Par exemple, INT2 n'est pas traduit en SMALLINT (Looping conserve alors le type de script, ce qui est déjà bien !), BPCHAR(1) n'est pas traduit en CHAR(1), etc.
J'imagine qu'un module de traduction des types par SGBD supporté n'est pas quelque chose de simple à mettre en œuvre, mais ça permettrait d'améliorer encore plus l'outil de rétroconception s'il était capable de faire cette traduction.

ced

[Paprick]

Bonjour,

En fait, lors de la rétroconception, Looping applique les types définis dans l'option "SGBD cible" du menu "MLD - LDD" dans la fenêtre "Propriétés", et ce quel que soit le SGBD qui a généré le DDL (parmi ceux connus de Looping bien sûr).

Merci de m'indiquer si cela fonctionne comme tu le souhaites.

[ced]

Bonjour Paprick,

Merci pour ta réponse.
Le mieux est de partir d'un exemple relativement simple.
Voici le script SQL issu d'un pg_dump (outil de sauvegarde de PostgreSQL) en me limitant à la structure (pas les données) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CREATE TABLE services ( id_service int2 NOT NULL, code_service bpchar(10), nom_service varchar(50) NULL, CONSTRAINT services_pkey PRIMARY KEY (id_service));
CREATE TABLE sgbd ( id_sgbd int2 NOT NULL, nom_sgbd varchar(50) NOT NULL, CONSTRAINT sgbd_pkey PRIMARY KEY (id_sgbd));
CREATE TABLE dba ( id_dba int2 NOT NULL, nom_dba varchar(50) NOT NULL, prenom_dba varchar(50) NULL, id_service int2 NULL, CONSTRAINT dba_pkey PRIMARY KEY (id_dba), CONSTRAINT dba_id_service_fkey FOREIGN KEY (id_service) REFERENCES services(id_service));
CREATE TABLE produits ( id_produit int2 NOT NULL, nom_produit varchar(50) NOT NULL, chef_produit varchar(50) NULL, id_service int2 NULL, CONSTRAINT produits_pkey PRIMARY KEY (id_produit), CONSTRAINT produits_id_service_fkey FOREIGN KEY (id_service) REFERENCES services(id_service));
CREATE TABLE serveurs ( id_serveur int2 NOT NULL, nom_serveur varchar(50) NOT NULL, ip_serveur bpchar(15) NOT NULL, id_service int2 NOT NULL, CONSTRAINT serveurs_pkey PRIMARY KEY (id_serveur), CONSTRAINT serveurs_id_service_fkey FOREIGN KEY (id_service) REFERENCES services(id_service));
CREATE TABLE instances ( id_serveur int2 NOT NULL, id_sgbd int2 NOT NULL, port bpchar(5) NOT NULL, version_sgbd varchar(50) NULL, actif bool DEFAULT true NULL, CONSTRAINT instances_pkey PRIMARY KEY (id_serveur, id_sgbd, port), CONSTRAINT instances_id_serveur_fkey FOREIGN KEY (id_serveur) REFERENCES serveurs(id_serveur), CONSTRAINT instances_id_sgbd_fkey FOREIGN KEY (id_sgbd) REFERENCES sgbd(id_sgbd));
CREATE TABLE serveur_dba ( id_serveur int2 NOT NULL, id_dba int2 NOT NULL, CONSTRAINT serveur_dba_pkey PRIMARY KEY (id_serveur, id_dba), CONSTRAINT serveur_dba_id_dba_fkey FOREIGN KEY (id_dba) REFERENCES dba(id_dba), CONSTRAINT serveur_dba_id_serveur_fkey FOREIGN KEY (id_serveur) REFERENCES serveurs(id_serveur));
CREATE TABLE bases ( id_base int2 NOT NULL, nom_base varchar(50) NOT NULL, id_serveur int2 NOT NULL, id_sgbd int2 NOT NULL, port varchar(5) NOT NULL, CONSTRAINT bases_pkey PRIMARY KEY (id_base), CONSTRAINT bases_id_serveur_id_sgbd_port_fkey FOREIGN KEY (id_serveur,id_sgbd,port) REFERENCES instances(id_serveur,id_sgbd,port));
CREATE TABLE bases_produits ( id_base int2 NOT NULL, id_produit int2 NOT NULL, CONSTRAINT bases_produits_pkey PRIMARY KEY (id_base, id_produit), CONSTRAINT bases_produits_id_base_fkey FOREIGN KEY (id_base) REFERENCES bases(id_base), CONSTRAINT bases_produits_id_produit_fkey FOREIGN KEY (id_produit) REFERENCES produits(id_produit));

Je crée un nouveau modèle dans Looping, et je lui indique PostgreSQL comme SGBD cible.
Voici ce que donne la rétro-conception :


On voit que le type des clés primaires (INT2 sous PostgreSQL pour un entier court, soit SMALLINT) n'est pas reconnu par Looping.
Idem pour la donnée CODE_SERVICE de l'entité SERVICES (bpchar = char pour PostgreSQL).
Enfin, la donnée ACTIF de l'entité INSTANCES a "bool DEFAULT true" comme type, au lieu d'un type booléen et une valeur par défaut à vraie.

J'espère que ce petit exemple illustre bien une partie du problème...

ced

[Paprick]

Bonjour,

En fait, il faut comprendre que Looping ne peut identifier que des types dont il a connaissance dans le SGBD de référence ; sinon, il crée un type libre.
La solution consiste donc à lui enseigner les types qu'il n'utilise pas par défaut.
Pour cela, il faut aller, depuis le menu principal, dans "Paramètres LDD" -> "Configuration du SGBD personnalisé".
Choisir PostgreSQL dans la zone "basé sur" et faire les adaptations souhaitées (par exemple, remplacer SMALLINT par INT2).
Il suffit ensuite de choisir "Personnalisé" dans l'option "SGBD cible" et ça devrait fonctionner comme souhaité .

Merci de me tenir informé.

[ced]

OK, je vais tester cette solution.
Autre possibilité : parser le script généré par pg_dump en remplaçant les types, via un script, pour le rendre compatible avec Looping. Cette solution-là fonctionne également.
Je te tiens au courant des tests dès que je les ai menés.

ced