Discussion :

[Morji2810]

Bonjour,

Je suis entrain de mettre à jour une application java existante. Pour ce faire, j'ai besoin de faire un update sur une clé primaire.
(Pourquoi un update sur une clé primaire? : la table oracle sur laquelle je travaille est renseignée lors du batch 3 d'une chaine de traitement. On m'a demandé de faire en sorte de renseigner cette table au cours du 1er batch dans un souci de traçabilité. En revanche, l'id, la clé primaire de la table est générée sous un format que l'on doit garder au batch 3. Donc je renseigne bien ma table au batch 1 avec un id tempo, mais lors du batch 3, je dois écraser l'id tempo par le nouvel id généré par ce batch. C'est à ce moment là que je souhaite donc faire donc un update sur la clé primaire).

J'ai cherché comment faire ça et j'ai trouvé la solution des trigger (si j'ai bien compris).
Ma 1ère question est donc: est-ce qu'un trigger peut effectivement m'aider à faire un update sur une clé primaire?
Ma 2nd: si oui, est-ce que cette syntaxe est correcte sachant que je vais récupérer dans mon code java la valeur ici indiquée comme '9999999' ?

Code :

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

1
2
3
4
5
6
7
8
create trigger updateMaTableT
before update on maTable
for each row
when(new.maTable_idndoc <> old.maTable_idndoc)
begin
  insert into maTable (maTable_idndoc)
  values ('9999999')
end;

Ma 3ème (et là je ne suis probablement pas au bon endroit pour cette question): dans mon code java, dois-je mettre uniquement ma requête SQL d'update ou bien dois-je mettre le tout, c'est à dire du "create trigger" jusqu'au "end;" ?

Par avance, un grand merci pour vos infos et votre aide.

[aieeeuuuuu]

Bonjour,

C'est un peu confus. Normalement, une clef primaire ne devrait jamais être mise à jour. C'est pour cela qu'il convient de choisir une clef asémantique, c'est à dire n'ayant aucun sens particulier pour votre SI. Typiquement, une valeur numérique auto-incrémentée.
Dans votre cas, vous devriez ajouter une colonne contenant la valeur que vous obtenez à votre étape 3 (et mettre une contrainte d'unicité sur cette colonne).

[Morji2810]

Bonjour,

Merci pour votre retour,
En fait, j'ai ajouté une colonne qui contient mon id temporaire. Mais (forcément), je ne peux pas remplir ma table sans remplir le champ de la clé primaire, alors j'ai copié mon id temporaire dans ma clé primaire. De fait, je peux insérer la ligne entière.

Je suis entièrement d'accord sur le fait une clé primaire ne doit pas être changée, mais étant donné l'ensemble de la chaine de traitement faite sur cette table, je ne peux faire autrement.
Y-a t-il un moyen de contourner ça? Est-ce que je peux tout de même faire un update sur ma clé primaire?

[aieeeuuuuu]

J'ai tout de même l'impression que vous devriez passer votre clef primaire en clef candidate et garder votre identifiant initial comme clef primaire pour la table...
bref...

oui, vous pouvez faire une UPDATE qui vise la clef primaire.
Avez-vous des contraintes d'intégrités référençant cette clef primaire ?

[Morji2810]

Non pas de contrainte particulière sur cette clé primaire.

En revanche, un détail, je pense important, la clé primaire de la table est l'ensemble de champ1 et champ2. Il n'y que sur le champs 1 que je souhaite faire l'update. Toujours possible ??

[aieeeuuuuu]

Techniquement, oui... tant que vous ne violez pas de contrainte.

[Morji2810]

D'accord. Du coup, partant de cette "espérance", j'ai vu que je pouvais faire ça via un trigger. Est-ce bien le cas?
Voici le trigger que j'ai tenté de créer:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
 
CREATE TRIGGER updateMaTableT
before UPDATE ON maTable
FOR each row
when(new.maTable_idndoc <> old.maTable_idndoc)
begin
  INSERT INTO maTable (maTable_idndoc)
  VALUES ('9999999')
end;

Du coup, je copie mes questions :
Ma 1ère question est donc: est-ce qu'un trigger peut effectivement m'aider à faire un update sur une clé primaire?
Ma 2nd: si oui, est-ce que cette syntaxe est correcte sachant que je vais récupérer dans mon code java la valeur ici indiquée comme '9999999' ?

merci:

[skuatamad]

Les explications sont effectivement confuses.

Voici comment je comprends le contexte :
- Une table est chargée dans un batch 3
- Le chargement de la table doit être modifié
- La modification est faite dans le batch 1, déjà là je décroche...

est-ce qu'un trigger peut effectivement m'aider à faire un update sur une clé primaire?

En faisant un insert dans le trigger, je ne comprends pas bien comment ça aide pour faire un update...

est-ce que cette syntaxe est correcte sachant que je vais récupérer dans mon code java la valeur ici indiquée comme '9999999' ?

Le trigger est compilé dans oracle, '9999999' n'a donc aucun sens et java ne passera pas de paramètre au trigger, il faut peut être utiliser :new.maTable_idndoc par exemple.

[Morji2810]

Désolée, c'est difficile d'expliquer clairement sans connaitre l'ensemble de la chaine de traitement. Je réessaye:

- Effectivement, ma table est remplie au batch 3 (et c'est durant ce batch que l'on génère la clé primaire au format que l'on souhaite)
- Je dois la remplir au batch 1, c'est ce que j'ai fait.

Et mon problème arrive ici. Car il m'est totalement possible de remplir la table au batch 1 SAUF pour la clé primaire qui, compte tenu des différents traitements, ne peut être générée qu'au batch 3.

Ce que je souhaite donc, c'est modifier le batch 3 de telle sorte à ce qu'il génère comme à son habitude l'id que l'on souhaite et qu'il vienne alors écraser l'id de la clé primaire que j'ai été obligé de remplir dans le batch1 (puisque forcément clé primaire oblige sans quoi je ne pourrais remplir aucune ligne dans ce batch 1).

J'espère que c'est un peu plus claire?

Du coup, comment dois-je faire mon trigger?

Merci encore

[aieeeuuuuu]

1 - Comment, et par qui (SQL, Java ?) est calculée la nouvelle clef primaire ?
2 - Pourquoi ne pas garder la clef primaire qui a été attribuée à l'étape 1 (quel est l’intérêt de changer une clef primaire dans votre contexte ?)

[skuatamad]

Ben du coup quel est l'intérêt du trigger, il suffit d'écrire l'update qui va bien dans le batch 3, non ?

[Morji2810]

Ben du coup quel est l'intérêt du trigger, il suffit d'écrire l'update qui va bien dans le batch 3, non ?

Non, j'ai déjà tenté mais bien entendu ça ne fonctionne pas. On ne peut modifier une clé primaire. c'est pour ça que je pensais contourner cette règle via un trigger.

1 - Comment, et par qui (SQL, Java ?) est calculée la nouvelle clef primaire ?
2 - Pourquoi ne pas garder la clef primaire qui a été attribuée à l'étape 1 (quel est l’intérêt de changer une clef primaire dans votre contexte ?)

La nouvelle clé primaire est calculé par un dev java. Elle se faire en concaténant plusieurs données que n'avons qu'à l'issu du batch 3 et qui nous permet de retrouver, de traçer chaque document via cet id à n'importe quel moment dans les différentes chaines de traitement puisque l'on sait à quoi il doit ressembler.

C'est pour cela que je ne peux garder la clé primaire calculée dans l'étape 1: car de fait je ne saurai pas à quoi doit ressembler mon id et je perds notre volonté de pouvoir tracer chaque document quelque soit le traitement en cours parmi tous les traitements existant pour un document.

[aieeeuuuuu]

Non, j'ai déjà tenté mais bien entendu ça ne fonctionne pas.

Il aurait fallu commencer par là !!! quel erreur obtenez-vous ?

La nouvelle clé primaire est calculé par un dev java. Elle se faire en concaténant plusieurs données que n'avons qu'à l'issu du batch 3

Si c'est de la simple concaténation de données pourquoi ne pas le faire directement dans la base de données.

[skuatamad]

On ne peut modifier une clé primaire.

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
SQL> create table t (id number primary key, c varchar2(5));
 
Table created.
 
SQL> insert into t values (1,'test1');
 
1 row created.
 
SQL> insert into t values (2,'test2');
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> update t set id = 3 where id = 1;
 
1 row updated.
 
SQL> commit;
 
Commit complete.
 
SQL> select * from t;
 
        ID C
---------- -----
         3 test1
         2 test2
 
SQL>

c'est pour ça que je pensais contourner cette règle via un trigger.

De quelle règle s'agit-il ?
Quel message d'erreur est renvoyé lors de l'update ?

[Morji2810]

Je crois que je viens de résoudre mon problème, je ne me sert ni de trigger ni d'update sur la clé primaire. Je génère tout simplement l'id au format que l'on souhaite. En important dans mon projet toutes les classes dont j'ai besoin, ça a l'air de fonctionner et Oracle ne fait pas la tête. Il me faut faire maintenant quelques tests unitaires pour confirmer que tout est ok.

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
SQL> CREATE TABLE t (id number PRIMARY KEY, c varchar2(5));
 
TABLE created.
 
SQL> INSERT INTO t VALUES (1,'test1');
 
1 row created.
 
SQL> INSERT INTO t VALUES (2,'test2');
 
1 row created.
 
SQL> commit;
 
Commit complete.
 
SQL> UPDATE t SET id = 3 WHERE id = 1;
 
1 row updated.
 
SQL> commit;
 
Commit complete.
 
SQL> SELECT * FROM t;
 
        ID C
---------- -----
         3 test1
         2 test2
 
SQL>

Excellente démonstration, j'apprends donc quelque chose. Je suppose alors que mon message d'erreur venait du fait que je souhaitai modifier un et un seul champs de la clé primaire qui est en réalité constituée de 2 champ. Probable??
(Je ne me souviens plus exactement du message d'erreur).

En tout cas, un grand merci pour votre implication et vos propositions.: