Discussion :

[laffreuxthomas]

Bonjour, je souhaiterai savoir s'il est possible de r�cup�rer la valeur g�n�r�e par postgres, dans le cas d'une clef primaire serial.

... et ceci au travers d'une connexion JDBC d'un programme Java.

Merci d'avance

Thomas

[GrandFather]

Bonjour,

Dans la m�me transaction et apr�s ta requ�te INSERT, lance la requ�te :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

select currval('nom_de_la_sequence') as nouv_id;

nouv_id contiendra la derni�re valeur de la s�quence correspondant � ton champ serial

[laffreuxthomas]

Ok merci beaucoup. Du coup j'ai une question de newbie : comment puis-je d�terminer le nom de la s�quence ? Il me le donne au moment de la cr�ation de la table c'est �a ? Mais y-a-t'il un moyen de le d�terminer � post�riori ?

[laffreuxthomas]

Et dans le cas d'acc�s concurrent, y-a-t'il un risque que la valeur soit p�rim�e quand je la lis ? Ou bien le fait d'y acc�der dans la m�me transaction que l'insert me garantie que �a sera la bonne valeur ?

[GrandFather]

comment puis-je d�terminer le nom de la s�quence ? Il me le donne au moment de la cr�ation de la table c'est �a ? Mais y-a-t'il un moyen de le d�terminer � post�riori ?

Tu peux d�duire le nom de la s�quence en ajoutant le suffixe '_seq' au nom de ton champ serial (tu as �galement la possibilit� de cr�er ta s�quence manuellement et de choisir son nom, mais c'est rarement utile)

Et dans le cas d'acc�s concurrent, y-a-t'il un risque que la valeur soit p�rim�e quand je la lis ?

D'autres sessions peuvent effectivement faire appel entre temps � la fonction nextval(), qui incr�mente la s�quence et renvoie la nouvelle valeur. Cependant, nextval() est atomique et renvoie une valeur distincte du compteur � chaque session qui l'utilise. Il n'y a donc pas de risque de conflits entre les sessions. Par contre, tu n'as pas de garantie que le num�ro renvoy� par currval() est bien celui actuellement enregistr� dans la s�quence. Mais ce n'est pas grave, car tu es en revanche s�r que c'est bien celui renvoy� par le dernier nextval() dans ta session.

Ou bien le fait d'y acc�der dans la m�me transaction que l'insert me garantie que �a sera la bonne valeur ?

L'inclusion de currval() dans une transaction n'est en rien une obligation et n'est qu'une suggestion de ma part ; elle s'appuie sur les principes suivants :

- currval() renvoie une erreur si nextval() n'a pas �t� appel� au pr�alable dans la m�me session. En l'appelant apr�s un INSERT, je suis s�r que nextval() a �t� appel�.

- j'utilise essentiellement les SERIAL comme cl�s �trang�res pour des relations ma�tre/d�tails. Apr�s l'INSERT initial dans la table ma�tre suivront vraisemblablement des INSERT dans les tables d�tails avec la valeur renvoy�e par currval(). En pla�ant le tout dans une transaction, je m'assure de la consistence et de la robustesse de ma base.

Un point important : il ne peut pas y avoir de rollback sur un nextval().

[laffreuxthomas]

Merci infiniment GrandFather !!!