Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

PostgreSQL Discussion :

Rollback / Commit conditionnelles dans une fonction


Sujet :

PostgreSQL

  1. #1
    Candidat au Club
    Rollback / Commit conditionnelles dans une fonction
    Bonjour,

    Je suis nouveau au forum, je ne connais pas bien postgresql, je souhaite faire un rollback ou commit suivant si j'ai une erreur dans une fonction
    ou pas

    Exemple : Insertion d'une ligne dans une table si j'ai une exception (erreur) faire rollback si non commit
    et cela dans une fonction complexe.

    Mais j'ai compris que dans une fonction on peut pas faire rollback ou commit, quelqu'un peut m'aider à savoir comment je pourrai poser une condition
    pour valider l'insertion (Commit) ou l'annuler par Rollback suite à l’exécution de la fonction (je suis obligé de créer une fonction pour gérer un ensemble des tables ) ,

    Merci de votre aide

  2. #2
    Expert éminent sénior
    bonjour,

    C'est au traitement principal de savoir à quel moment les données sont cohérentes et qu'il faut "commiter" la transaction.
    En effet, une fonction peut ne réaliser qu'une partie des modifications en base pour le traitement.
    Il serait incohérent de valider cette partie des modifications alors que d'autres mises à jour sont faites par appel à d'autres fonctions ou procédures stockées ou en directement par requête et ne seront éventuellement pas commitées car tomberont en erreur.
    De plus, une même fonction pouvant être appelée par plusieurs traitements, ce qui est acceptable pour l'un est peut être une erreur grave pour l'autre.
    Raison de plus pour gérer les commit/rollback dans le traitement principal

    Au sujet du "comment" il faut donc réaliser l'ensemble des opérations de mise à jour directement ou par appel à des fonctions ou procédures, puis, si tout s'est bien passé, commiter l'ensemble.
    Si au contraire, l'une des étapes de mise à jour produit une erreur grave, alors on fait le rollback et on ignore les MàJ suivantes.
    Tout ça dans le traitement principal.

    Le détail des instructions liées aux transactions est ici : https://www.postgresql.org/docs/9.1/sql-begin.html

  3. #3
    Rédacteur

    Citation Envoyé par escartefigue Voir le message
    bonjour,

    C'est au traitement principal de savoir à quel moment les données sont cohérentes et qu'il faut "commiter" la transaction...
    Hélas ce sont les limites de fonctionnement de PostGreSQL qui n'a jamais implémenté la notion de Procédure stockée !

    Tous les autres SGBDR, permettent de piloter les transactions comme on le souhaite dans toutes les routines (procédures, declencheurs...) exception faite des fonctions dont le principe est d'être utilisé indirectement par une requête, une procédure, un trigger une vue....

    PostGreSQL ayant commis les stupides conneries de :
    • confondre fonction et procédures
    • et de ce fait interdire que ces fonctions puissent avoir leur propre autonomie transactionnelles !


    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  4. #4
    Expert éminent
    Citation Envoyé par Wha001 Voir le message

    Mais j'ai compris que dans une fonction on peut pas faire rollback ou commit
    Bonjour, on peut mais il faut que le client soit en autocommit.
    L'explication: https://medium.com/@FranckPachot/pos...s-9b57cb909067
    Franck Pachot - dbi services - Oracle ACE Director - OCM 12c - Oak Table member - twitter: @FranckPachot - blog: blog.pachot.net

  5. #5
    Rédacteur/Modérateur

    Citation Envoyé par SQLpro Voir le message
    Hélas ce sont les limites de fonctionnement de PostGreSQL qui n'a jamais implémenté la notion de Procédure stockée !

    Tous les autres SGBDR, permettent de piloter les transactions comme on le souhaite dans toutes les routines (procédures, declencheurs...) exception faite des fonctions dont le principe est d'être utilisé indirectement par une requête, une procédure, un trigger une vue....

    PostGreSQL ayant commis les stupides conneries de :
    • confondre fonction et procédures
    • et de ce fait interdire que ces fonctions puissent avoir leur propre autonomie transactionnelles !


    A +
    Encore une fois, que d'affirmations non vérifiées !
    Et que d'insultes inutiles !

    PostgreSQL a implémenté les transactions dans les procédures stockées à partir de la version 11.
    Il n'y a vraiment que les butés qui ne changent décidément pas !!!
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  6. #6
    Rédacteur

    Citation Envoyé par ced Voir le message
    Encore une fois, que d'affirmations non vérifiées !
    Et que d'insultes inutiles !
    Je ne voit pas ou tu voit des insultes...




    PostgreSQL a implémenté les transactions dans les procédures stockées à partir de la version 11.
    Il n'y a vraiment que les butés qui ne changent décidément pas !!!
    De manière très incomplète comme le souligne Pachot....
    1) pas de possibilité de transaction explicite en mode non autocommit (bug ?...)
    2) pas de possibilité de changer le niveau d'isolation en cours d'exécution de la transaction
    3) pas de transactions imbriquées
    4) pas de transactions "autonomes" à la oracle (fonctionnalité à mon sens parfaitement idiote !, mais c'est un autre débat)
    5) pas de possibilité de définir différents niveaux d'isolation pour les différentes tables d'une même requête

    C'est donc loin d'être complet en plus d'être bugué !

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  7. #7
    Rédacteur/Modérateur

    Citation Envoyé par SQLpro Voir le message
    Je ne voit pas ou tu voit des insultes...
    Citation Envoyé par SQLpro Voir le message
    les stupides conneries
    Rappel de la définition d'une insulte, dixit le Larousse : "Parole ou acte qui offense". C'est là où je vois des insultes.
    Mais c'est peut-être votre langage habituel...?

    Citation Envoyé par SQLpro Voir le message
    PostGreSQL qui n'a jamais implémenté la notion de Procédure stockée !
    Citation Envoyé par SQLpro Voir le message
    De manière très incomplète
    Alléluia ! Donc, vous reconnaissez que c'est implémenté, contrairement à votre message précédent... On progresse...

    Citation Envoyé par SQLpro Voir le message
    C'est donc loin d'être complet en plus d'être bugué !
    Allons ! Un habitué de Microsoft comme vous devrait savoir que ce n'est pas un bug, "it's a feature !"...
    D'ailleurs, le comportement mis en avant par pachot ne vient pas du moteur, mais des clients (psql et jdbc).

    Alors certes, on peut toujours demander des fonctionnalités supplémentaires, et l'implémentation des transactions dans les procédures dans PostgreSQL est loin d'être complète, mais il est faux d'affirmer de manière péremptoire que ça n'a jamais été fait.

    À bon entendeur...
    Rédacteur / Modérateur SGBD et R
    Mes tutoriels et la FAQ MySQL

    ----------------------------------------------------
    Pensez aux balises code et au tag
    Une réponse vous a plu ? N'hésitez pas à y mettre un
    Je ne réponds pas aux questions techniques par message privé, les forums sont là pour ça

  8. #8
    Candidat au Club
    Solution avec lex exceptions dans les fonctions
    Bonjour,

    Merci pour vos retours, j'ai réussi à trouver une solution pour appliquer le rollback si besoin en utilisant les exceptions dans les fonctions
    que j'utilise

    Merci Encore

###raw>template_hook.ano_emploi###