Forums PostgreSQL.fr

Papychampi

Membre

Transactions dans une procédure stocké

Bonjour à tous!

j'ai une une procédure stockée qui créé des produits dans mes tables tout est expliquer ici http://forums.postgresql.fr/viewtopic.php?id=3716 et du coup j'ai un petit problème... Il s'avère que lors de la création de la deuxième cadence le numéro récupéré est le dernier mais d'avant la création de la commande...

Du coup je viens implorer votre aide... Comment fait on pour gérer les transactions en procédures stockées...?

Cordialement,

Papychampi

Marc Cousin

Membre

Re : Transactions dans une procédure stocké

On ne peut pas faire ça dans PostgreSQL. Une procédure s'exécute dans la transaction de la fonction qui l'appelle. Par contre, la procédure devrait voir le résultat de tout ce qu'elle a fait, et donc devrait voir ses propres modifications…

---

Marc.

Papychampi

Membre

Re : Transactions dans une procédure stocké

Et bien apparemment ce n'est pas le cas...

gleu

Administrateur

Re : Transactions dans une procédure stocké

Et pourtant, Marc a raison.

---

Guillaume.

edlm

Membre

Re : Transactions dans une procédure stocké

Bonjour,

@Papychampi votre requête n'est pas claire.

Si je pars sur l'hypothèse que ce que vous cherchez à faire dans votre procédure stockée est de récupérer le numéro de série suivant d'une colonne de type séquence
vous pouvez pour une table ressemblant à ca:

CREATE TABLE test(
    num_serie SERIAL,
    data1 integer...
);

faire la requête suivante dans votre procèdure stockée:

...
INSERT INTO test(data1) VALUES(9999) RETURNING num_serie INTO ma_variable_de_ma_procedure_stockee;
...

qui placera dans ma_variable_de_ma_procedure_stockee le numéro de série suivant.

Le principe est, si c'est possible,de laisser faire la base pour attribuer le numéro de série.

Pourquoi "si c'est possible"  ? Parce que les séquences PostgreSQL peuvent avoir des "trous" car même si la transaction dans laquelle se situe l'appel à nextval est annulée (rollback)
le numéro de série est considéré quand même comme attribué (il ne sera pas réutilisé).

Si votre application ne tolère pas ce genre de saut il faut trouver une autre solution qui risque d'être beaucoup beaucoup moins simple avec plein d'inconvénients... mais dont le principe
va être de de bloquer certrains accès concurrent à la table pendant qu'une transaction attribue un nouveau numéro. Comme ca je dirais que la transaction enveloppante (celle dans laquelle s'exécute
la procédure stockée) doit être positionnée sur SERIALIZABLE et que l'application doit être prête à gérer les annulations des transactions en cours.

---

Éric