[ERP-53] Migrer les tables Client + sous-collections + référentiels comptables #27

Merged
malio merged 3 commits from feature/ERP-53-migrer-tables-client-m1 into develop 2026-06-01 15:19:44 +00:00
Showing only changes of commit 034301ceaf - Show all commits
+19 -3
View File
@@ -84,10 +84,18 @@ final class Version20260601000000 extends AbstractMigration
$this->addSql('DROP TABLE payment_delay');
$this->addSql('DROP TABLE tva_mode');
// Retire uniquement les 4 types seedes par cette migration. Les autres
// types eventuels (CRUD futur) sont preserves.
// Retire uniquement les 4 types seedes par cette migration ET restes
// orphelins (aucune `category` ne les reference). Sans la clause
// NOT EXISTS, le DELETE casse sur la FK RESTRICT category.category_type_id
// des qu'une categorie pointe sur l'un d'eux. Symetrique du
Outdated
Review

down() échouera dès qu'une category référence un de ces 4 types.

Contexte : down() supprime les 4 codes seedés, mais category.category_type_id est une FK ON DELETE RESTRICT (cf. M0 Version20260527164000). client_address_category impose justement des catégories de type SECTEUR/AUTRE (RG-1.29) — donc en prod ces types auront des category rattachées.

Cause : DELETE FROM category_type WHERE code IN (...) est bloqué par la FK RESTRICT dès qu'une seule category pointe sur un de ces types → down() lève une exception et le rollback de migration est impossible. (En dev/test ça passe pour l'instant uniquement parce qu'aucune fixture ne crée encore de category.)

Recommandation : ne supprimer que les types orphelins, p.ex. DELETE FROM category_type WHERE code IN (...) AND NOT EXISTS (SELECT 1 FROM category c WHERE c.category_type_id = category_type.id). Cohérent en plus avec le ON CONFLICT DO NOTHING du up() : la migration ne devrait défaire que ce qu'elle a réellement inséré.

**`down()` échouera dès qu'une `category` référence un de ces 4 types.** **Contexte** : `down()` supprime les 4 codes seedés, mais `category.category_type_id` est une FK `ON DELETE RESTRICT` (cf. M0 `Version20260527164000`). `client_address_category` impose justement des catégories de type `SECTEUR`/`AUTRE` (RG-1.29) — donc en prod ces types auront des `category` rattachées. **Cause** : `DELETE FROM category_type WHERE code IN (...)` est bloqué par la FK RESTRICT dès qu'une seule `category` pointe sur un de ces types → `down()` lève une exception et le rollback de migration est impossible. (En dev/test ça passe pour l'instant uniquement parce qu'aucune fixture ne crée encore de `category`.) **Recommandation** : ne supprimer que les types orphelins, p.ex. `DELETE FROM category_type WHERE code IN (...) AND NOT EXISTS (SELECT 1 FROM category c WHERE c.category_type_id = category_type.id)`. Cohérent en plus avec le `ON CONFLICT DO NOTHING` du `up()` : la migration ne devrait défaire que ce qu'elle a réellement inséré.
// `ON CONFLICT (code) DO NOTHING` du up() : on ne defait que ce qu'on a
// reellement cree et qui n'est pas reutilise.
$this->addSql(<<<'SQL'
DELETE FROM category_type WHERE code IN ('DISTRIBUTEUR', 'COURTIER', 'SECTEUR', 'AUTRE')
DELETE FROM category_type
WHERE code IN ('DISTRIBUTEUR', 'COURTIER', 'SECTEUR', 'AUTRE')
AND NOT EXISTS (
SELECT 1 FROM category c WHERE c.category_type_id = category_type.id
)
SQL);
}
1
@@ -220,6 +228,14 @@ final class Version20260601000000 extends AbstractMigration
$this->addSql('CREATE INDEX idx_client_created_by ON client (created_by)');
$this->addSql('CREATE INDEX idx_client_updated_by ON client (updated_by)');
// Index sur les FK des referentiels comptables — coherence avec les autres
// FK deja indexees ci-dessus (Postgres n'indexe pas automatiquement les
// colonnes portant une FOREIGN KEY).
$this->addSql('CREATE INDEX idx_client_tva_mode_id ON client (tva_mode_id)');
$this->addSql('CREATE INDEX idx_client_payment_delay_id ON client (payment_delay_id)');
$this->addSql('CREATE INDEX idx_client_payment_type_id ON client (payment_type_id)');
$this->addSql('CREATE INDEX idx_client_bank_id ON client (bank_id)');
// Unicite metier partielle (Q4) : nom de societe insensible a la casse,
// parmi les non-archives ET non soft-deletes uniquement. Pas d'index
// unique sur siren ni email.