Discussion :

[banaouas.medialog]

bonjour,
base Oracle 10 XE
Est-t-il possible de récupérer le "metadata" d'un record ?
Cela me serait utile pour récupérer les résultats d'une proc avec les noms des champs correspondant aux champs du record et non pas les noms des champs manipulés à l'intérieure de la proc.

A titre d'exemple, (voir le ddl ci-après) je souhaite récupérer des données nommées (ID, CLE, LIB) et non pas (TBL_ID, TBL_CLE, TBL_LIB).

Coté client, J'accède aux données via python, delphi, etc. ...

Code :

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

1
2
3
4
5
6
7
CREATE TABLE MYTABLE
(
  TBL_ID  NUMBER,
  TBL_CLE VARCHAR(20), 
  TBL_LIB VARCHAR(60)
  CONSTRAINT PK_MYTABLE PRIMARY KEY (TBL_ID) ENABLE
);

Code :

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

1
2
3
4
5
6
7
TYPE MYTABLE_Rec IS RECORD (
    ID NUMBER,
    CLE VARCHAR(20),
    LIB VARCHAR(60)
);
 
TYPE MYTABLE_Cur IS REF CURSOR RETURN MYTABLE_Rec;

Code :

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

1
2
3
4
5
6
7
PROCEDURE MYTABLE_Proc (curRet IN OUT MYTABLE_Cur, MOT VARCHAR) IS
BEGIN
  OPEN curRet FOR select TBL_ID, TBL_CLE, TBL_LIB
  from MYTABLE
  where upper(TBL_LIB) like upper(MOT)
  order by TBL_LIB;
END;

[orafrance]

merci de penser aux balises code à l'avenir.

A part ça, as-tu essayé et quelle erreur as-tu rencontré ?

[pifor]

Je ne crois pas qu'on peut le faire directement en référençant le nom des champs du RECORD. C'est possible indirectement en renommant dans le SELECT le nom des colonnes (sans avoir à utiliser de type RECORD):

Code :

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
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
SQL> drop table mytable;
 
Table dropped.
 
SQL>
SQL> CREATE TABLE MYTABLE
  2  (
  3    TBL_ID  NUMBER,
  4    TBL_CLE VARCHAR(20),
  5    TBL_LIB VARCHAR(60),
  6    CONSTRAINT PK_MYTABLE PRIMARY KEY (TBL_ID) ENABLE
  7  );
 
Table created.
 
SQL>
SQL> insert into mytable values(0, 'OK', 'OK');
 
1 row created.
 
SQL>
SQL> create or replace package pmt
  2  is
  3  PROCEDURE MYTABLE_Proc (curRet IN OUT SYS_REFCURSOR, MOT VARCHAR);
  4  end;
  5  /
 
Package created.
 
SQL> show errors
No errors.
SQL>
SQL> create or replace package body pmt
  2  is
  3  PROCEDURE MYTABLE_Proc (curRet IN OUT SYS_REFCURSOR, MOT VARCHAR) IS
  4  BEGIN
  5    OPEN curRet FOR SELECT TBL_ID ID, TBL_CLE CLE, TBL_LIB LIB
  6    FROM MYTABLE
  7    WHERE upper(TBL_LIB) LIKE upper(MOT)
  8    ORDER BY TBL_LIB;
  9  END;
 10  end;
 11  /
 
Package body created.
 
SQL> show errors
No errors.
SQL>
SQL> var rc refcursor;
SQL>
SQL> exec pmt.mytable_proc(:rc, 'OK');
 
PL/SQL procedure successfully completed.
 
SQL> column lib format a20
SQL> print rc
 
        ID CLE                  LIB
---------- -------------------- --------------------
         0 OK                   OK
 
SQL>

[banaouas.medialog]

mon problème n'est pas relatif à une erreur d'exécution.
Les procédures auxquelles je m'intéresse sont fournies dans un package et sont construites sur le même modèle que j'ai donné en exemple.
Elles sont documentées en référençant les champs des records.
Dans ma démarche de les encapsuler dans des "services" générés dynamiquement, j'ai estimé qu'il fallait que ces services doivent présenter une interface (paramétres et données en sortie) identiques à ce qui est spécifié par la doc.
Sans cette contrainte, ca fonctionne très bien ... sauf que les développeurs consommant ces services ont du mal à s'y retrouver entre deux nommages différents.
Voila pourquoi je tente de faire en sorte que le curseur retourné par la proc ait le même format (nom et type des champs) que le record auquel il fait référence. C'est d'autant plus déroutant que dans la déclaration du curseur, il est bien dit que le curseur "retourne" un record... :
TYPE MYTABLE_Cur IS REF CURSOR RETURN MYTABLE_Rec;
à croire que cela ne sert à rien !

[pifor]

Un curseur n'est qu'un moyen de définir une requête. La définition du type du curseur définit le type des colonnes retournées mais pas le nom des colonnes. Le nom des colonnes peut être redéfini dans la requête utilisé par le curseur mais pas pas la déclaration du type du curseur.

Normaliser les interfaces c'est très bien mais pourquoi ne pas garder le nom des colonnes des tables ? Si vous ne voulez pas garder les noms des colonnes des tables, alors vous pouvez peut-être définir des vues pour renommer toute les colonnes de façon plus propre et utiliser ces vues dans des curseurs.

[banaouas.medialog]

J'insiste sur le fait que le package des API ainsi que leur documentation sont fournis par un tiers, je dois donc veiller à les préserver dans l'état dans lequel ils me sont livrés.
C'est bien dommage que ce ne soit QUE le type des colonnes du cursor qui soit défini par le record et pas aussi le nom, car cela permettrait de masquer les noms d'origine des champs des tables, en donnant des noms "metier". D'autre part, la doc désigne les champs des records et pas ceux des tables manipulées à l'intérieur des proc (c'est pas plus mal ...).

Je veux bien redéfinir des vues mais ca ne ferait que repousser le pb un peu plus loin: dans la mesure du possible, je tiens à ce que cela se fasse dynamiquement: ca évite un cycle lourd de maintenance suite aux mises à jours éventuelles du package.

Ce serait TRES intéressant d'accéder à la définition complète d'un record.
J'espère que cela existe parmis les USER_OBJECTS, etc ...