exception qui annule mes Inserts [Résolu]

[giova_fr]

Bonjour.

J'ai fais une fonction qui selon les conditions fait un RAISE EXCEPTION.
Jusque la tout va bien.

Mon probleme est que, avant de lever l'exception, je veux faire un insert dans une table de log. Or le RAISE visiblement annule toutes les requettes qui ont eu lieu dans ma fonction, dont mon fameux Insert.

Comment faire svp dans une fonction, pour faire un INSERT avant un RAISE EXCEPTION qui ne soit pas annulé par ce dernier?

[SQLpro]

Postez le code de votre fonction et un exemple d'appel.

A +

[giova_fr]

Bonjour, et merci pour votre attention.

Voici un exemple, purement academique mais représentatif du but souhaité (voir ses commentaires):

Code :

1
2
3
4
5
6
7
8
9
CREATE OR REPLACE FUNCTION "MaFunc"(userid integer) 
BEGIN; 
IF userid = 0 THEN 
     --Je veux forcer ce Insert!!!!!!!!!!!!!!!!!! 
     INSERT INTO log_error(caller, description) VALUES('MaFunc', 'userid is 0'); 
     -- Et je veux aussi que cette exception soit levée
     RAISE EXCEPTION 'userid can''t be equal to 0'; 
ENDIF; 
END;

[estofilo]

Le RAISE EXCEPTION provoque un ROLLBACK qui annule l'effet de l'INSERT.
Pour éviter cela il faudrait que l'INSERT soit dans une transaction autonome, mais postgres n'a pas cette fonctionnalité.
On peut quand même arriver à un résultat similaire avec le module dblink qui permet d'ouvrir une autre connexion indépendante à la base, tout en restant dans le contexte d'une fonction serveur.

[giova_fr]

aie

et en prennant le probleme à l'envers :
peut on créer un trigger abonné au raise exception?

comme il s'executerait apres, je pourrait en fonction du code erreur/message faire mon insert dedans !?!?

En fait je ne veux pas dépendre du client qui pourrait oublier de logguer certaines exceptions (entre autre erreur/oubli possible de la part d'un client).

PS : ca me serait tres difficile d'ajouter un module à postgres.

Merci encore pour votre aide.

[estofilo]

Sans ajouter de module, je ne connais pas de solution à ce problème.

[SQLpro]

non, ça n'a pas grand sens.
Expliquez le fonctionnel qui vous à conduit à tenter cela. Il existe certainement un moyen de faire cela différemment.

A +

[giova_fr]

Le souhait d'envoyer une exception, est de forcer le code client a reagir. Si je mettais de simples notification, le client devrait les interroger apres chaque action, ce qui garanti un oubli tot ou tard lor du developpement du client.

Ma fonction en base tient plusieurs roles :

• s'assurer de la cohérence technique des données qu'elle recoit=> Exception
• S'assurer que le client a le droit de l'appeller => Exception + ban (le insert)
• Elle touche a des données sensibles liées à la sécurité, donc elle doit pouvoir noter dans des tables des historiques. (intel a demandé ceci alors qu'il n'avait pas le droit)

Voila donc l"idée en résumé : forcer le client (Exceptions qu'il ne peut ignorer).
Enregistrer des données de facon indépendante, meme si le process a échoué.

[SQLpro]

Donc, vous faites fausse route sur toute la ligne ....

Envoyé par giova_fr

Ma fonction en base tient plusieurs roles :
s'assurer de la cohérence technique des données qu'elle recoit=> Exception

pas du tout ! il suffit d'utiliser des contraintes. Une base de données relationnelle sans pose de contraintes c'est de la connerie. Autant utiliser Excel !

S'assurer que le client a le droit de l'appeller => Exception + ban (le insert)

pas du tout ! il suffit d'utiliser les privilèges... Une base de données relationnelle sans mettre des utilisateurs SQL et des privilèges c'est de la connerie. Autant utiliser Cobol !

[*] Elle touche a des données sensibles liées à la sécurité, donc elle doit pouvoir noter dans des tables des historiques. (intel a demandé ceci alors qu'il n'avait pas le droit)

La du fait que 1 et 2 ont empêché cela la seule chose qui vous reste est de tracer les modification et suppression de données validés. Dans ce cas soit le SGBDR dispose d'un système de traçabilité d'exécution (comme c'est le cas avec CDC, change Tracking ou Database Audit de MS SQL Server), soit c'est à vous de le faire à la main... Ce qui sera votre cas si vous utilisez PG.

Bref, vous avez fait fausse route !

A +

[estofilo]

Envoyé par giova_fr

Ma fonction en base tient plusieurs roles :

• s'assurer de la cohérence technique des données qu'elle recoit=> Exception
• S'assurer que le client a le droit de l'appeller => Exception + ban (le insert)
• Elle touche a des données sensibles liées à la sécurité, donc elle doit pouvoir noter dans des tables des historiques. (intel a demandé ceci alors qu'il n'avait pas le droit)

Du point de vue de l'architecture, la première fonctionnalité a sa place dans les fonctions plpgsql mais les deux autres seraient plutôt à remonter dans un middleware.
On peut aussi imaginer que les fonctions plpgsql renverraient des codes d'erreur au lieu de faire un RAISE mais l'issue est très dépendante de ce que fait le client.
Si le code client n'est pas "coopératif", c'est un argument en plus en faveur du middleware plutôt que de laisser un accès à une connexion SQL.

[giova_fr]

Merci pour toutes vos réponses.

Il est vrai que j'ai voulu trop en demander à la base : gérer les données, faire le gendarme et le greffier.

Le middleware (que j'avais deja commencé) devra donc gérer la sécurité. Juste que j'aurai aimé pouvoir graver quelques regles dans la base pour la rendre plus indépendante...

pas du tout ! il suffit d'utiliser les privilèges

La dessus je me suis mal exprimé, il ne s'agit pas de savoir si on a le droit ou non d'appeller une fonction, mais, en fonction des arguments, et de données présentes dans plusieurs tables, bref, en fonction du contexte, savoir si la requette est légitime ou suspecte. Et en cas de suspition, le noter dans une table où personne n'a le droit d'écrire... Cette fonction ne retourne rien au client, sauf ===> exception

Je vais donc trouver un pattern qui me garantisse que mon middleware tienne compte des code erreur retournés sous forme de simple integer.

[SQLpro]

Envoyé par giova_fr

La dessus je me suis mal exprimé, il ne s'agit pas de savoir si on a le droit ou non d'appeller une fonction, mais, en fonction des arguments, et de données présentes dans plusieurs tables, bref, en fonction du contexte, savoir si la requette est légitime ou suspecte. Et en cas de suspition, le noter dans une table où personne n'a le droit d'écrire... Cette fonction ne retourne rien au client, sauf ===> exception

Encore une fois vous faites fausse route ! Il suffit de passer par des vues.... En principes toutes les applications devraient accéder aux données d'une base exclusivement par des vues et non directement aux tables.
Dans le pire des cas, si passer par des vues vous parait trop compliquées, vous pouvez passer uniquement par des routines stockées qui vont faire vos INSERT, UPDATE, DELETE...

A +

[giova_fr]

J'utilise l'excelent Pgadmin, donc les vues sont faciles à créer (requette graphique, puis copier coller).

On m'avait deja dit qu'il ne fallait passer que par des vues ou procédures, j'imagine que c'est pour ne pas rendre le code client dépendant de la structure de la base...

J'essaye d'aller dans ce sens, juste pour ne pas transformer la maintenance en enfer... meme si pour l'heure ca me rallentit plus qu'autre chose ...

Merci en tout cas pour toutes vos réponses, conseils, J'apprécie vraiment !
Je bascule le topic en résolu, meme si je continue à le surveiller...