Discussion :

[tatayo]

Juste pouvoir spécifier le nom d'un schéma pour une entité.

Dans ma BDD j'ai par exemple un schéma dictionnaire (avec les devises, pays, unités de mesure, calendrier), un schéma ERP, etc. Bref une quinzaine de schémas au total.
Donc j'aimerai pouvoir spécifier le nom du schéma dans la description des entités.
En l'état je dois reprendre le script généré pour ajouter le nom du schéma, car je ne peux pas le mettre directement dans le nom de la table (le . est systématiquement remplacé par un _),
ni dans la déclaration des FK.


Tatayo.

[Paprick]

Ca y est : problème reproduit (c'était ma roulette qui répondait mal ) !
Je vais donc regarder ça pour la version 4.1

[Paprick]

Juste pouvoir spécifier le nom d'un schéma pour une entité.

Donne-moi un exemple concret de ce que tu souhaiterais obtenir dans le DDL SQL.

[tatayo]

Voici un exemple:

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
CREATE TABLE wms.ARTICLE_COTES(
   ARCT_I_IDENT BIGINT IDENTITY,
   ARCT_F_LONGUEUR DECIMAL(8,3) NOT NULL default 0,
   ARCT_F_LARGEUR DECIMAL(8,3) NOT NULL default 0,
   ARCT_F_HAUTEUR DECIMAL(8,3) NOT NULL default 0,
   ARCT_F_PDS_BRUT DECIMAL(8,3) NOT NULL default 0,
   ARCT_F_PDS_NET DECIMAL(8,3) NOT NULL default 0,
   ARCT_T_CREATION DATETIME2 NOT NULL default current_timestamp,
   ARCT_T_MODIFICATION DATETIME2 NOT NULL default current_timestamp,
   UM_I_IDENT_POIDS TINYINT NOT NULL,
   UM_I_IDENT_DIMENSION TINYINT NOT NULL,
   ART_I_IDENT INT NOT NULL,
   CONSTRAINT PK_ARTICLE_COTES PRIMARY KEY(ARCT_I_IDENT),
   CONSTRAINT FK_ARTICLE_COTES_UNITE_MESURE_POIDS FOREIGN KEY(UM_I_IDENT_POIDS) REFERENCES dictionnaire.UNITE_MESURE(UM_I_IDENT),
   CONSTRAINT FK_ARTICLE_COTES_UNITE_MESURE_DIMENSION FOREIGN KEY(UM_I_IDENT_DIMENSION) REFERENCES dictionnaire.UNITE_MESURE(UM_I_IDENT),
   CONSTRAINT FK_ARTICLE_COTES_ARTICLE FOREIGN KEY(ART_I_IDENT) REFERENCES erp.ARTICLE(ART_I_IDENT)
);

La table doit être crée dans le schéma wms, et elle fait référence à une table du schéma dictionnaire (pour les unités de mesure), et une autre du schéma erp (l'article).

Tatayo.

[Paprick]

En fait, il suffirait que Looping ne transforme pas les "." en "_" dans les noms logiques des classes d'entités et associations au moment de la génération du MLD et du DDL : c'est ça ?

[tatayo]

C'est une solution, pourquoi pas.

Ou avoir une option qui ajoute le nom du modèle au noms des tables.
Mais se pose alors le "problème" des entités appartenant à un modèle externe.

"Pas touche au point", c'est finalement une solution.

Tatayo.

[Paprick]

C'est noté pour Looping 4.1 !
De plus, pour ne pas encombrer le MCD, il suffira de n'indiquer le nom complet avec schéma que dans le nom logique.

[escartefigue]

Ca y est : problème reproduit (c'était ma roulette qui répondait mal ) !
Je vais donc regarder ça pour la version 4.1

Ça me rassure, j'ai cru un instant que c'était spécifique à ma configuration

Merci de l'avoir pris en compte

[escartefigue]

C'est noté pour Looping 4.1 !
De plus, pour ne pas encombrer le MCD, il suffira de n'indiquer le nom complet avec schéma que dans le nom logique.

En même temps, il me semble que tous les SGBD proposent une commande très simple permettant de modifier le schéma en cours.
Par exemple, avec SET CURRENT SCHEMA pour DB2, Oracle et PostGre ou ALTER USER... WITH DEFAULT_SCHEMA pour SQL server
Pour MySQL / MariaDB c'est encore plus simple, dans la mesure où les schémas ne sont pas gérés, mais allègrement confondus avec les databases , la commande USE suffit !

Est-il nécessaire de le gérer au niveau du modèle ? Ça n'a pas vraiment de sens, le modèle étant le même quel que soit le schéma (sauf évolution en test pas encore livrée en prod, mais ça c'est une histoire de version, c'est différent). Il me semble préférable d'ajouter la commande ad hoc dans le script en fonction du SGBD et le tour est joué.

Qu'en pensez-vous ? Paprick, Tatayo ? François si tu traînes tes guêtres dans le coin ?

[tatayo]

Changer le schéma par défaut ne resous qu'une partie du problème.
Si dans une table du schéma X est déclarée une FK qui "pointe" vers une colonne d'une table du schéma Y, il faudra quand même modifier le script pour "corriger" la déclaration de la FK.

Tatayo.

[escartefigue]

Autant pour moi, j'aurais du lire avec plus d'attention la demande, je n'avais pas vu la problématique multi-schéma !

On peut résoudre ce genre de soucis en créant des objets de type alias ou synonym (selon les SGBD et leur version) :

Par exemple, dans ma table Schema1.T1, je veux référencer une colonne de la table Schema2.Tx
Je crée un alias Schema1.A1 qui référence Schéma2.TX et ensuite, ma FK fait référence directement à A1, sans préciser le schéma

[tatayo]

Effectivement, je n'avais pas pensé au alias.
Par contre j'ai déjà eu du mal avec les contraintes d'intégrité, j'imagine déjà leur tête si je parle d'alias ...

Tatayo.

[Paprick]

Dans tous les cas, accepter les "." dans les noms de classes d'entités et associations ne pose pas de problème pour le futur Looping, et ça semble être la solution la plus simple et efficace pour résoudre ce genre de problème.

[fsmrel]

Ave Paprick,

Pour une future version...

Je ne sais pas si cette question t’a déjà été posée, auquel cas pardonne-moi la répétition.

Etant donné qu’une base de données a son métabolisme, au stade du langage de définition de données de SQL, à savoir l’instruction CREATE TABLE, il a été prévu (en 1988 pour DB2 par exemple) qu’on puisse utiliser la clause ON DELETE CASCADE pour supprimer les lignes ciblées par la contrainte FOREIGN KEY.

Serait-il possible de mettre en oeuvre une case à cocher (oui/non) pour demander la génération de cette clause et éviter ainsi qu’on code soi-même L’ALTER TABLE qui va bien ? Ça n’est évidemment pas une tâche prioritaire, puisqu’il s’agit très égoïstement du confort du DBA...

[Paprick]

Salut François,

Non seulement la question a déjà été posée, mais la réponse a déjà été mise en oeuvre dans l'actuelle version 4 de Looping !
Tu trouveras l'option correspondante dans la fenêtre "Propriétés", partie "MLD-SQL", option "Proposer cascade".
Dis-moi si ça te convient !

[fsmrel]

Merci Paprick pour ta réactivité, alors que tu dois être bien chargé par ailleurs. Vu l'heure...

Je n’avais pas vu l’option...

Cela dit, le choix est manifestement global : tout ou rien. Je souhaite pour ma part que ce choix puisse être fait à maille fine, au niveau d’un objet (classe d’entité, patte d’association...)

Par ailleurs, j’ai essayé les différentes options : il ne passe rien, jamais de cascade en vue. Qu’ai-je raté ?

[Paprick]

Une fois l'option choisie, tu dois définir si tu l'appliques ou pas sur chaque lien, sachant que l'option les valides ou non par défaut au moment de leur création.

[fsmrel]

Vu l'arbre en boule. Pour les liens concernés, j'ai coché la case ON DELETE CASCADE, mais toujours rien au niveau du code SQL. Je ne t'embête plus, je vais rejoindre Morphée...

En tout cas, merci pour tout !

[Paprick]

Vu l'arbre en boule. Pour les liens concernés, j'ai coché la case ON DELETE CASCADE, mais toujours rien au niveau du code SQL.

Surprenant... Es-tu sûr d'avoir vérifié la présence de la cascade sur la bonne table ? La cascade se fait sur la table "d'en face" !
Sinon, envoie-moi ton modèle que je regarde ce qui se passe...

[fsmrel]

Ave Paprick,

Après avoir dormi une paire d’heures, j’ai rallumé mon pc, ouvert le .loo en cause, et, ô magie ! les DELETE CASCADE sont présents. Je pense qu’il devait suffire de fermer le fichier puis le rouvrir. Quoi qu’il en soit, la nuit porte conseil et, all’s well that ends well, comme disait l’autre.

Encore merci et pardonne moi de t’avoir pris de ton précieux temps.