création d'une transaction de facturation [Résolu]

[kuntagp]

Bonjour je souhaite utiliser postgresql pour faire un soft de facturation, voici le synoptique de la fonction nouvelachat:

-debut d'une transaction

-créer nouvel facture avec facture_ID (serial) ;

-créer de nouvel ligne de facture avec idfacture(facture_ID);

-commiter la transaction ou faire un rollback.


Je voudrais savoir si:

-cela peut se faire?

-l'incrementation de ID et son ajout dans les lignes de facture ne se fait qu'au moment du commit (afin de m'éviter de perdre des numéros)?

en vous remerciant d'avance.

[punkoff]

bonjour,

logiquement oui, regardez du côté de la clause "returning" lors d'un insert.

l'incrementation de ID et son ajout dans les lignes de facture ne se fait qu'au moment du commit (afin de m'éviter de perdre des numéros)?

Ceci n'a pas de sens.
La clef primaire se doit d'être unique dans votre table, de ce fait la séquence associé à votre ID sera incrémentée systématiquement lors d'une demande d'insert.

Si vous avez un rollback celle-ci ne se décrémentera pas.

En effet, prenons un exemple simple :

Code :

1
2
3
4
5
6
7
 
début de transaction A (TA)
début de transaction B (TB)
TA incrémente le serial
TB incrémente le serial
TB commit
TA rollback

Si, lors du rollback de TA, la séquence se remet à l'ancienne valeur lors de la demande d'incrémentation de TA vous allez avoir un problème au prochain insert.

[kuntagp]

Tout d'abord merci de votre réponse, n'étant pas un spécialiste de postgresql n'y aurait il pas moyen de forcer le comportement suivant.

-TA(insert num facture)
-TB(insert n lignes de facture liées avec IDfacture)
-commit TA+TB
-rollback TA+TB

[punkoff]

Bonjour,

Non, une fois commité vous ne pouvez plus rollbacké.


De plus pour pouvoir faire en simultané un commit ou rollback entre 2 transactions liées il va falloir utiliser des transactions distribuées (XA) par exemple.


Par contre, votre schéma n'est-il pas plutôt comme ceci ?
TA
création commande
création lignes
commit TA ou rollback TA

ou
TA
création commande
commit TA ou rollback TA

TB (si pas de rollback de TA)
création lignes
commit TB

[estofilo]

La séquence garantit l'unicité des valeurs, mais pas que les valeurs se suivent exactement (il peut y avoir des trous).
Pour des numéros de facture on ne peut pas utiliser une séquence à cause de ça.

Une solution possible est d'utiliser un compteur dans une colonne qui sera verrouillé par la transaction qui créé une nouvelle facture:
1) verrouillage compteur de facture
2) incrémentation compteur de facture
3) insertion facture
4) commit (qui déverouille implicitement le compteur)

[kuntagp]

Désolé j'ai fait une petite erreur voici ce que je voulais schématiser:
-TA(insert num facture)
-TB(insert n lignes de facture liées avec IDfacture)
-submit TA+TB
-rollback TA+TB ou commit

est ce faisable et est ce que cela me garantirait de ne pas avoir des trous dans mes IDfacture?

Je ne sais pas si la solution du verrou est envisageable car l'application est sensée être multi-utilisateur, ce verrou ne risque-t il pas de bloquer les autres usagers?

[punkoff]

Si vous utilisez un serial (qui est une séquence) pour générer vos numéro de facture vous aurez des trous quoi que vous fassiez.

[estofilo]

Envoyé par kuntagp

Je ne sais pas si la solution du verrou est envisageable car l'application est sensée être multi-utilisateur, ce verrou ne risque-t il pas de bloquer les autres usagers?

Non car une transaction d'insertion de facture ne dure que quelques millisecondes donc personne n'est gêné sauf s'il y en a des milliers par seconde.
Lorsque les utilisateurs sont en train de saisir, l'appli n'a encore ouvert aucune transaction.

Il faut voir que d'une manière générale, des verrous sont posés implicitement par le SGBD quand on fait des écritures avec UPDATE et parfois INSERT, généralement ce n'est pas un problème, c'est une solution justement pour éviter des incohérences en multi-utilisateurs.
D'ailleurs la manière la plus simple de verrouiller le compteur de facture est de faire un simple UPDATE dessus avec sa valeur actuelle plus un.

[kuntagp]

Merci de vos reponses je vais tenter de contourner le problème avec du code c++

[SQLpro]

Le fait d'avoir des "trous" de numération dans vos factures n'est pas un problème dans le sens ou vous pouvez justifier que cette facture a été annulée.
Il faudra cependant emmètre une facture d'avoir pour contrebalancer la facture annulée.
En bref, vous ne devez jamais rollbacker une facturation, quoi qu'il arrive, mais émettre une seconde facture d'avoir dont le total annule l'ensemble.

A +