Recuperer l'identifiant aprés insertion d'un tupple [Résolu]

[bambou]

Bonjour,

Je vien du forum PHP ou on m'a renvoyé par ici..

Est-ce que quelqu'un saurait si il existe une fonction equivalente à MySQL mysql_insert_id() pour postgres?

à savoir qui retournerai l'identifiant d'un tupple que l'on vient d'inserer sans avoir a passer une nouvelle requete?

merci


ps : le post relatif dans le forum php

[ced]

Bonjour,
Dans Postgres, je ne crois pas qu'il y ait de fonction d'auto incrément comme dans MySQL. Les clefs peuvent être générées par des séquences.
Donc, si tu as le nom de l'objet séquence utilisé sur ta table, l'instruction currval('nom_sequence') renvoit la dernière valeur employée par cette séquence.

ced

[bambou]

l'instruction currval('nom_sequence') est une instruction SQL non?

Si je veux l'utiliser il faut que je fasse une requete SQL..ça revient plus ou moin au meme que de refaire un select

[Smortex]

Salut

ced, ta méthode peut poser problème car l'INSERT et le SELECT qui suit ne sont pas effectués de façon atomique. Si une nouvelle ligne est insérée dans la table entre les deux instructions, le SELECT renverra la mauvaise valeur.

Il ne reste que deux solutions:

• Faire un SELECT en cherchant les valeurs qui viennent d'être insérées. Si ces valeurs sont uniques, pas de problème, sinon on peut avoir plusieurs lignes de résultat et là c'est un autre problème.
• Utiliser l'extension non-standard de PostgreSQL 8.2+ RETURNING documentée ici : http://www.postgresql.org/docs/8.2/i...ql-insert.html

[budtucker]

Smortex, de spéculer qu'un insert puisse se produire entre un insert et un select (surtout sur une séquence) est un peu (beaucoup !!) improbable. A part si on bosse sur une application d'environ une centaine d'accès à la seconde !! Je crois que seul SourceForge.com peut se vanter de ça.

Bien sûr, comme tu l'as indiqué, on peut également utiliser la forme suivante :

J'ai une table jour avec id_jour en serial :

Code :

1
2
3
INSERT INTO jour(
             madate, lib_jourferie)
    VALUES ( now(), 'aujourdhui') RETURNING id_jour;

A+

[GrandFather]

Envoyé par Smortex

ced, ta méthode peut poser problème car l'INSERT et le SELECT qui suit ne sont pas effectués de façon atomique. Si une nouvelle ligne est insérée dans la table entre les deux instructions, le SELECT renverra la mauvaise valeur.

L'INSERT et le SELECT ne sont effectivement pas atomiques, mais en l'occurrence cela n'a pas d'importance car currval() renverra le dernier numéro "consommé" dans la même session. Même si des sessions ouvertes par d'autres clients insèrent d'autres enregistrements entre l'INSERT et le SELECT, la cohérence de la valeur renvoyée par currval() est garantie pour la session qui l'appelle. Seule contrainte, il faut impérativement qu'un nextval() ait été appelé auparavant dans la même session, ce qui est le cas ici puisque l'insertion d'un enregistrement comportant un champ du type SERIAL déclenche automatiquement l'appel de cette fonction.

budtucker >> compter sur la chance pour que la base conserve son intégrité est s'exposer tôt ou tard à un rappel douloureux de la Loi de Murphy...

[bambou]

Merci beaucoup pour toutes ces réponses,

je vais voir si il est possible de mettre en place l'extension returning sur la BD que j'utilise, ce serait l'ideal

encore merci a vous tous

L'aggrégat 'RETURNING' est vraiment intéressant. Le problème est si l'on veut migrer vers un autre SGBD, ça ne sera pas interprété !!
La ou les requetes seront bonnes à refaire!

[bambou]

dans mon cas précis ça ne pose pas de probleme il est possible qu'il y ait migration des données vers une autre architecture de la base, mais le moteur restera posgres, donc le returning me convient parfaitement

[Shepard]

Euh est-ce que la fonction nextval() ne sert pas précisément à ce genre de situation ?

Je veux dire: On commence par

Code :

SELECT NEXTVAL('sequence');

puis:

Code :

INSERT INTO TABLE ( id, col2, col3, ... ) VALUES ( [résultat de la requête du dessus], val2, val3, ... );

Enfin moi c'est comme ça que je fais ^^ Pas d'extension supplémentaire nécessaire, on est absolument certain de ne pas "mélanger" les id, c'est simple, beau, rapide, cool, bien, chouette ^^

Dites moi si je me trompe svp

[bambou]

Pour recadrer un peu les choses : mon but était d'essayer de diminuer le nombre de requetes, passer de 3 à 2 :
- Un select pour vérifier l'existance du tupple
- Un insert pour inserer le tupple
- Un select pour récupérer l'identifiant

pour la derniere requete que je fasse un select classique ou un SELECT NEXTVAL('sequence');, cela ne change rien, j'ai toujours 3 requetes...

...alors qu'avec le returning, la 3eme requete n'est plus nécessaire.

J'aurais été en php5 j'aurais pu tout faire avec une seule requete, mais malheuresement ce n'est pas le cas :'(

[Shepard]

En effet ça ne change rien du point de vue du nombre de requêtes, j'avais pas compris le débat désolé

[Smortex]

Envoyé par Shepard

Euh est-ce que la fonction nextval() ne sert pas précisément à ce genre de situation ?

[couic]

C'est moins lourd que de refaire une sélection sur tous les champs après, et comme le champ est indexé, la recherche est simplifiée. Tu perds juste la flexibilité offerte en mettant une valeur par défaut pour ce champ et le laisser gérer par PostgreSQL. Donc si tu es dans une situation telle que celle décrite par GrandFather, je pense qu'il est encore plus simple de faire un SELECT sur currval() après l'insertion.

Envoyé par bambou

J'aurais été en php5 j'aurais pu tout faire avec une seule requete, mais malheuresement ce n'est pas le cas :'(

Il me semblais que le moteur magique qui accède à la base de données en exécutant seulement une requète sur deux est prévu dans PHP 7.0 seulement (Les goto de PHP 6.0 étants requis pour implémenter cette extension)...

[bambou]

Envoyé par Smortex

Il me semblais que le moteur magique qui accède à la base de données en exécutant seulement une requète sur deux est prévu dans PHP 7.0 seulement (Les goto de PHP 6.0 étants requis pour implémenter cette extension)...

rhooo c'est pas gentil de ce moquer des noobs qui s'exprime mal!! vilain canaillou va

non ce que j'entendais par par

J'aurais été en php5 j'aurais pu tout faire avec une seule requete, mais malheuresement ce n'est pas le cas :'(

c'est qu'avec un try/catch...imlémenté dans php5...j'aurais pu faire l'insert directement et récupérer l'erreur, si erreur il y avait. le 'tout' désignait les 2 premieres requetes (a savoir, rechercher l'existance du tupple et l'inserer si il n'existe pas), ce qui effectivement n'était pas trés bien formulé, je le reconnais

mais au final 2 requetes sont nécessaires, on est d'accord

[TheGzD]

Bonjour !

Je me permets de faire remonter le sujet, car il n'a pas vraiment été apporté de réponse à la question initiale (dont la réponse m'intéresse (si si si sans déconner )) :

Envoyé par bambou

Est-ce que quelqu'un saurait si il existe une fonction equivalente à MySQL mysql_insert_id() pour postgres?

Dans mon cas je dispose du PGresult * renvoyé par la dernière requête passée et forcément du PGconn * de ma connexion.

S'il n'y a toujours pas d'autres moyens que ceux énoncés dans ce topic, je me résignerai, la mort dans l'âme, à truander

Merci d'avance.

[SQLpro]

Envoyé par bambou

Pour recadrer un peu les choses : mon but était d'essayer de diminuer le nombre de requetes, passer de 3 à 2 :
- Un select pour vérifier l'existance du tupple
- Un insert pour inserer le tupple
- Un select pour récupérer l'identifiant

Là vous faites fausse route complète !!!!

1) entre la requête 1 et la 2 les données peuvent changer du fait des actions concurrentes des utilisateurs. Le risque est donc énorme d'obtenir une incohérence de la base de données tôt ou tard.... et je vous renvoie sur le commentaire précédent : http://www.developpez.net/forums/d36...e/#post2256364 (loi de Murphy)

Le plus simple est d'incorporer la requête 1 dans la 2. Exemple :

Code :

1
2
INSERT INTO MaTable
WHERE ...

Ensuite compter le nombre de ligne insérées... ceci est faisable pour toute requête du côté client, comme du côté serveur !

Code :

1
2
3
4
5
6
DECLARE  
   nb_lignes integer;  
BEGIN  
   INSERT INTO ...
   GET DIAGNOSTICS nb_lignes := ROW_COUNT;  
   IF nb_lignes  = 0 ...

2) diminuer le nombre de requête n'est pas une fin en soi. Ce qui importe dans un SGBDR est de diminuer les temps de verrouillage d'un côté (serveur) et les aller retours de l'autre côté (client).
Dans ce sens l'utilisation des procédures stockées (Dans PostGreSQL ce sont des fonctions) ne peut que vous apporter des bienfaits et répondre aux deux problématiques....

A +

[TheGzD]

Pour répondre à la question initiale, je crois que la requête suivante doit renvoyé le résultat souhaité :

Code :

SELECT LASTVAL()

[TheGzD]

Je repasse en coup de vent pour confirmer que cette requête retourne effectivement le résultat souhaité