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
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
Bonjour,
Dans la même transaction et après ta requête INSERT, lance la requête :
nouv_id contiendra la dernière valeur de la séquence correspondant à ton champ serial
Code : Sélectionner tout - Visualiser dans une fenêtre à part select currval('nom_de_la_sequence') as nouv_id;
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 ?
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 ?
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)Envoyé par laffreuxthomas
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.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 ?
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 :Ou bien le fait d'y accéder dans la même transaction que l'insert me garantie que ça sera la bonne valeur ?
- 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().
Merci infiniment GrandFather !!!
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager