Discussion :

[devlop78]

Bonjour,

Je suis en train de voir l'ensemble des fonctionnalités des SGBDR, et je suis passé de Mysql à PostegreSQL en local pour pouvoir le faire (sauf assertions qui ne semblent pas possible).

Lors de la violation d'une contrainte CHECK, mon exécution retourne une erreur. De façon général, que ce soit en local directement sur phpPgAdmin, ou à travers un langage tel que PHP, savoir si une exécution a eu lieue ou non est primordiale.

Seulement, là j'ai créé un TRIGGER, et j'utilise une "fonction" (j'ai pas réussi autrement ^^). Je vais ensuite passer aux procédures stockées.

Donc ma question est : quelle va être la réaction face au ROLLBACK ? Si je lance une transaction dans ma procédure stockée et que le ROLLBACK est lancé, recevrais-je une erreur, ou dois-je me retourner en plus une valeur que je définirai comme telle ?

Et actuellement, ma fonction lancée par mon trigger BEFORE INSERT est :

Code :

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

1
2
3
4
 
  BEGIN  
ROLLBACK;
  END;

Cela a bien été enregistré par PostegreSQL. Lorsque je tente d'ajouter une ligne (un tuple, c'est ça ?), il me retourne :

ERREUR:

SPI_execute_plan_with_paramlist failed executing query "ROLLBACK": SPI_ERROR_TRANSACTION
CONTEXT: PL/pgSQL function "gen_cle_client" line 4 at instruction SQL

Malheureusement, en voyant le message, je n'ai pas l'impression que c'est une bonne nouvelle ... Je crois surtout qu'il n'a pas aimé le ROLLBACK. Bien qu'en testant ROLLBACK directement en SQL, ça ne lance aucune erreur. Est-ce du à l'autocommit, je ne sais pas ... tout ce dont j'ai besoin, c'est de pouvoir arrêter une procédure stockée avec ou sans transaction (autre que autocommit) en emmettant un message d'erreur à l'utilisateur du SGBDR (le langage Php par exemple), et pareil pour le trigger. Ici j'ai mis brutalement un ROLLBACK, mais c'est dans l'objectif de refuser une entrée avec une analyse plus complète apparemment non possible avec CHECK(), et qui d'après moi serait plutot le rôle des assertions (par exemple, controler en fonction des autres lignes de la table, voire des autres tables comme l'exemple du client/prospect avec une unicité commune des clés primaires).

Je vais, en attendant, faire le tour du forum, mais j'espère avoir quelques pistes ;o

Merci, a+

[devlop78]

Au fait, j'ai vu le tuto sur les séquences ... mais auto increment n'existe pas ? Je ne le trouve pas dans phpPgAdmin et comme souvent depuis la transition, je viens d'essayer ALTER TABLE et il n'en veut pas ... il y a beaucoup trop de différence de syntaxe avec mySQL

[CinePhil]

Au fait, j'ai vu le tuto sur les séquences ... mais auto increment n'existe pas ?

Non. Pour incrémenter une colonne, il faut utiliser une séquence. À la création de la table, le pseudo-type serial s'occupe de créer la séquence et de l'associer à la table.

il y a beaucoup trop de différence de syntaxe avec mySQL

AUTO_INCREMENT est une instruction particulière de MySQL comme le pseudo-type serial est une particularité de Postgresql. Il y a encore d'autres instructions dans les autres SGBD.
La norme SQL ne prévoit pas d'instruction pour auto-incrémenter une colonne à ma connaissance.

[devlop78]

OK. La réponse est très claire. Malheureusement, je passe des fois (beaucoup) trop de temps sur des choses qui ne le devrait pas en demander. Par exemple, en formation .NET, le formateur avait parlé de procédures stockée pour éviter que entre son SELECT et son INSERT, un autre INSERT apparaisse. Evidemment, le cours n'était pas sur SQL, sinon pour cet exemple, la contrainte d'unicité était bien plus appropriée, mais surtout que j'ai regardé les procédures stockées sur Google, surtout pour Mysql, et ils parlaient énormément de l'avantage d'atomicité, mais toujours sans suggérer que la transaction faisait elle-même les verrouillages. J'ai même regarder à ce sujet, c'est toujours rester flou. Les discutions et tutoriels sur PostegreSQL sont déjà bien plus clair là dessus : les verrous faits "maison", c'est "à fuir". Et puis, de ce que j'ai pu comprendre, et c'est quasi sûr, sinon pourquoi permettre les verrous (serialize etc), s'il n'en mettait pas. Bref, c'est pas clair. Pareil pour les règles PostegreSQL, je me demande si ce n'est pas l'équivalent des assertions. A coté, on trouve facilement des tutoriels sur les contraintes. Heureusement ! Et là c'est un régal :p

[devlop78]

Re:

http://www.postgresql.org/docs/9.0/s...l-trigger.html

Je cite

IF NEW.empname IS NULL THEN
RAISE EXCEPTION 'empname cannot be null';

J'essaie de mon coté hors procédure et fonction RAISE EXCEPTION, et il n'en veut pas. L'équivalent de throw new Exception serait effectivement super.

[devlop78]

Ca y est ! Ouf !

j'ai trouvé seulement après la valeur de retour VOID, donc j'ai mis INTEGER puisque NULL ne passait pas ...

Code :

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

1
2
3
4
5
6
BEGIN
RAISE EXCEPTION 'CECI EST UNE ERREUR';
RETURN 25;
END;
 
SELECT somefunc();

-- RESULTAT

Erreur SQL :

ERREUR: CECI EST UNE ERREUR


J'imagine donc que l'exception + un rollback (voir l'exception seule il me semble l'avoir vu) permettent de gérer cette ensemble dissociable arret transaction (si existe) + erreur

J'attends vos com :p

[SQLpro]

... la transaction faisait elle-même les verrouillages. J'ai même regarder à ce sujet, c'est toujours rester flou.

Lisez ce que j'ai écrit sur le sujet...
http://sqlpro.developpez.com/isolation-transaction/

A +

[devlop78]

Lisez ce que j'ai écrit sur le sujet...
http://sqlpro.developpez.com/isolation-transaction/

A +

Oui, j'ai pu lire des articles, et tu en as fait pas mal. J'ai notamment imprimé "Niveau d'isolation et anomalies transactionnelles" de Frédéric Brouard (différents modes de verrouillage avec tableau de comparaison), j'ai lu un article sur les "verrous mortels" (de mémoire, mais je ne sais plus dans lequel), j'ai imprimé "Bases de donneés relationnelles et contraintes SQL" de SQLpro", et j'ai pu retenir que l'on a des contraintes de lignes/table (CHECK, UNIQUE, etc), des contraintes de base (assertions), et après triggers qui sont des procédures stockées déclenchées, qui sont d'après moi des "évenements" au regard d'un langage événementiel. J'ai imprimé "Limiter la complexité du code applicatif grâce au SGBD" de Alain Defrance en cherchant une liste exhaustive et clair des contraintes (et la différence entre tous ces termes pas évidents au début), et qui m'a conforté dans la vision de division des responsabilités, vision que je développe de plus en plus avec l'orienté objet (abstraction/délégation). j'ai aussi imprimé une petite page ... voilà, par exemple "Les contraintes de table" : Elles valident la ligne d'une table. Tout est dit en une phrase, là où des fascicules entier sur le net échouent. Enfin, merci à vous ;o

[SQLpro]

La norme SQL ne prévoit pas d'instruction pour auto-incrémenter une colonne à ma connaissance.

Si :
1) IDENTITY
2) CREATE SEQUENCE
Font tous deux parties intégrantes de la norme SQL !
Voir mon bouquin pour de plus amples informations...

A +