fix(paiement): rendre colonnes legacy nullables + refactor Paiement/PaiementObjet

Migrations :
- V25 : numero_transaction nullable dans paiements (legacy V1 NOT NULL bloquant INSERT)
- V26 : autres colonnes legacy NOT NULL V1 (type_paiement, statut_paiement, etc.)
  rendues nullables pour alignement avec l'entité Paiement

Refactor Paiement/PaiementObjet : mise à jour entités, repository, resource, service
pour cohérence avec le nouveau module Versement. Tests associés supprimés/ajustés.
This commit is contained in:
dahoud
2026-04-15 20:23:30 +00:00
parent 5d028a10bf
commit 217021933e
12 changed files with 582 additions and 2317 deletions

View File

@@ -0,0 +1,13 @@
-- V25 : Rendre numero_transaction nullable dans la table paiements
--
-- Problème : la colonne numero_transaction est définie NOT NULL dans V1,
-- mais l'entité Paiement ne la mappe pas. Un paiement Wave créé en état
-- EN_ATTENTE n'a pas encore de numéro de transaction (celui-ci arrive via
-- le callback Wave après complétion). La contrainte NOT NULL empêche tout
-- INSERT et provoque un 500.
--
-- La colonne transaction_wave_id stocke déjà le session ID Wave ;
-- numero_transaction est distinct (ID de transaction finalisée chez Wave).
ALTER TABLE paiements
ALTER COLUMN numero_transaction DROP NOT NULL;

View File

@@ -0,0 +1,16 @@
-- V26 : Correction des colonnes legacy NOT NULL non mappées dans l'entité Paiement
--
-- Contexte : La table paiements a été créée par V1 avec des colonnes NOT NULL
-- (statut, type_paiement). Hibernate en mode "update" a ensuite ajouté les colonnes
-- métier réelles (statut_paiement, methode_paiement...) sans supprimer les anciennes.
-- Résultat : l'entité Paiement ne mappe pas ces colonnes V1, et tout INSERT échoue.
--
-- Solutions :
-- - type_paiement : équivalent fonctionnel de methode_paiement → nullable
-- - statut : remplacé par statut_paiement dans l'entité → nullable
ALTER TABLE paiements
ALTER COLUMN type_paiement DROP NOT NULL;
ALTER TABLE paiements
ALTER COLUMN statut DROP NOT NULL;