Numéros de séquence qui se suivent [Résolu]

[matech]

Bonjour,

J'utilise JPA couplé avec Hibernate et une BDD Oracle, j'utilise une séquence pour générer des identifiants. Or lorsqu'il y a des rollbacks, il annule les insertions et donc les identifiants en BDD ne se suive pas.

Comment les faire suivre ?

[MrCba]

Bonjour,

La séquence n'est pas sensible à la transaction. Ce qui est normal car si tu as deux transactions qui accèdent en même temps à la séquence, elles ne doivent pas avoir la même valeur.

On peut jouer avec un "select for update" pour créer une sorte de verrou à la séquence mais je te le déconseille.

La bonne question est plutôt pourquoi tu ne veux pas de trou dans ta séquence ?

[matech]

Les numéros doivent se suivre car cela est exigé, je ne cherche pas à les faire suivre pour le plaisir ;-). Il s'agit de numéro de facture.

[Jimmy_]

La solution est de gérer toi même ta séquence, c'est un peu périeux, mais faisable.

[DevServlet]

Envoyé par Jimmy_

La solution est de gérer toi même ta séquence, c'est un peu périeux, mais faisable.

, dans ton cas effectivement les séquences me paraissent moins adaptées, la solution serait de récupérer avant chaque insertion le max Id, l’incrémenter et insérer. Donc une stratégie de génération de clé manuelle me parait aussi mieux adaptée.

[tchize_]

En sachant que tu va ralentir d'autant ton application!


En effet, si le user A crée un facture, tu prend le numéro suivant dispo. (257 par exemple)
Si en parallèe B crée un facture, il ne pourra pas le faire tant que A n'aura pas commité ou fait de rollback (ben oui, on doit utiliser 258 ou réutiliser le 257?)

Bref, bon plaisir dans le code, mais dans tous les cas tu va devoir marquer dans JPA que c'est un ID assigné et non pas une séquence

Un autre solution serait d'essayer de laisser la DB gérer l'assignation des numéro de facture après le commit. Mais alors il te faudra une deuxième transaction pour relire la facture et connaitre son numéro.

En tout cas, pour moi, la clé primaire devrait être distincte du numéro de facture. Un clé primaire est une donnée technique qui sert à relier des données entre-elles. Un numéro de facture est une donnée buisness qui ne devrait pas être soumises au contraintes de la techniques. (Autrement dit si demain ton client veux créer deux factures avec le même numéro, le logiciel devrait être facilement ajustable)

[matech]

Effectivement la solution était de gérer moi-même mon numéro car les séquences ne sont pas rollbackable. J'ai donc utilisé une table fonctionnelle pour générer le numéro de séquence, elle fait ainsi parti de ma transaction et est donc rollbackable

[JeitEmgie]

Envoyé par tchize_

Un autre solution serait d'essayer de laisser la DB gérer l'assignation des numéro de facture après le commit. Mais alors il te faudra une deuxième transaction pour relire la facture et connaitre son numéro.

… pas vraiment une deuxième transaction, mais un deuxième round-trip vers la database : étant read-only, l'aspect transctionnel n'est pas nécessaire pour obtenir le numéro de facture alloué…

et comme on est dans un contexte ORACLE, on peut aussi tout faire en un round-trip transactionnel via une procédure stockée…
mais attention :
la numérotation continue implémentée par un système centralisé a des conséquences opérationnelles dont il faut avoir conscience (réseau de points de facturation : ils deviennent dépendants de l'accessibilité au système centralisé… or, il est parfois nécessaire de garantir que l'on puisse facturer à tout moment, quitte à de voir le faire "off-line"…)

Envoyé par tchize_

En tout cas, pour moi, la clé primaire devrait être distincte du numéro de facture. Un clé primaire est une donnée technique qui sert à relier des données entre-elles. Un numéro de facture est une donnée buisness qui ne devrait pas être soumises au contraintes de la techniques. (Autrement dit si demain ton client veux créer deux factures avec le même numéro, le logiciel devrait être facilement ajustable)

Pas seulement "pour vous" : pour n'importe qui a une connaissance autre que théorique du monde de l'entreprise, et non seulement pour les raisons ici invoquées mais aussi :

- même si la majorité des petites entreprises n'ont qu'un seul facturier de sortie, ce n'est pas une règle générale, et les séquences de numéro doivent être continues par facturier et non pas de manière globale;

- la numérotation peut être soumise à des règles particulières, comme une assez commune : "continue par période fiscale avec remise à zéro lors du passage à la suivante" (le numéro est alors préfixé par l'année…), mais des plus exotiques existent;

- …

bref : autant de raisons qui vous appuient dans ce constat :
un numéro de facture en particulier, et un numéro de document en général, doit être alloué de manière totalement indépendante de toute contrainte technique d'implémentation (et encore moins du RDBMS utilisé, cela va sans dire…) : ce genre de numérotation ne répond qu'à des règles business.
L'idéal étant que ces règles puissent être configurées indépendamment de toute programmation "en dur".