Migration TaxRef et position du lancement du script SQL post détection

[jpm-cbna]

Lors de la migration de TaxRef (v16 et v17), nous pouvons utilisé un script SQL exécuté après la détection des changements (2.2_taxref_changes_corrections_post_detections.sql.sample). Ce script me semble être lancé un peu trop tôt pour que la gestion de la migration se fasse simplement.

Il me semble être lancé AVANT que la nouvelle version de TaxRef soit mise à jour dans la table taxonomie.taxref.

Du coup, il n'est pas possible de désactiver certaines contraintes (ex. dans taxonomie.t_medias la contrainte check_is_cd_ref, dans gn_synthese.synthese la containte fk_synthese_cd_nom) dans le script de pré-détection pour les réactiver ensuite dans celui de post-détection. Il est donc nécessaire de modifier la table TaxRef (ancienne version) en insérant les nouveaux cd_nom, mettant à jour les cd_ref... C'est donc assez compliqué.

Pourquoi ne peut on pas lancer le script 2.2_taxref_changes_corrections_post_detections.sql après la mise à jour de la table TaxRef dans la base ? Cela permettrait de désactiver les contraintes dans le script de pré-détection pour les activer à nouveau dans le script de post-détection une fois le nouveau TaxRef importé.

[jacquesfize]

Bonjour @jpm-cbna,

De ce que je comprends, le fichier 2.2_taxref_changes_corrections_post_detections.sql n'est plus utilisé s'il existe (depuis la v15). Maintenant, le fichier intégrant ces changements est donné en paramètre de la ligne de commande flask taxref migrate-to-v17 apply-changes.

Je confirme qu'il est bien lancé avant la mise à jour de la table taxonomie.taxref

TaxHub/apptax/taxonomie/commands/migrate_taxref/commands_v17.py

Line 99 in 14614a7

analyse_taxref_changes(

Concernant la désactivation des contraintes liées à TaxHub, tu peux les effectuer dans ce script de post_detection, car elle seront recréés à la fin de l'import dans la table taxref.

TaxHub/apptax/taxonomie/commands/migrate_taxref/data/specific_taxref_v15_v16/3.2_alter_taxref_data.sql

Lines 304 to 334 in 14614a7

	------------------------------------------------
	------------------------------------------------
	-- REBUILD CONSTAINTS
	------------------------------------------------
	------------------------------------------------
	UPDATE taxonomie.t_medias m SET cd_ref = t.cd_ref
	FROM taxonomie.taxref t
	WHERE m.cd_ref = t.cd_nom AND NOT t.cd_nom = t.cd_ref;
	UPDATE taxonomie.cor_taxon_attribut m SET cd_ref = t.cd_ref
	FROM taxonomie.taxref t
	WHERE m.cd_ref = t.cd_nom
	AND NOT t.cd_ref = t.cd_nom;
	ALTER TABLE taxonomie.bib_noms
	ADD CONSTRAINT fk_bib_nom_taxref FOREIGN KEY (cd_nom)
	REFERENCES taxonomie.taxref (cd_nom) MATCH SIMPLE
	ON UPDATE NO ACTION ON DELETE NO ACTION;
	ALTER TABLE taxonomie.t_medias
	DROP CONSTRAINT IF EXISTS check_is_cd_ref,
	ADD CONSTRAINT check_is_cd_ref CHECK (cd_ref = taxonomie.find_cdref(cd_ref));
	ALTER TABLE taxonomie.cor_taxon_attribut
	DROP CONSTRAINT IF EXISTS check_is_cd_ref,
	ADD CONSTRAINT check_is_cd_ref CHECK (cd_ref = taxonomie.find_cdref(cd_ref));

Concernant les autres contraintes liées à GeoNature (e.g. fk_synthese_cd_nom), peut être ajouter la possibilité d'ajouter deux scripts : l'un exécuté avant l'import et l'autre après l'import ...

@migrate_to_v17.command()
@click.option("--keep-oldtaxref", is_flag=True)
@click.option("--keep-oldbdc", is_flag=True)
@click.option("--keep-cdnom", is_flag=True)
@click.option("--script_predetection", type=click.Path(exists=True))
@click.option("--script_postdetection", type=click.Path(exists=True))
@click.option("--script_premigration, type=click.Path(exists=True))
@click.option("--script_postmigration", type=click.Path(exists=True))
@with_appcontext
def apply_changes(
    keep_oldtaxref, keep_oldbdc, keep_cdnom, script_predetection, script_postdetection
):
    pass

P.S. nom de paramètre temporaire

[jpm-cbna]

@jacquesfize je ne savais pas effectivement que certaines contraintes sur l’existence du cd_ref étaient réactivées par le script de migration ! Donc, cela résoud effectivement une partie de mon problème.

Pour la contrainte fk_synthese_cd_nom sur la table gn_synthese.synthese, ta proposition de pouvoir insérer des scripts SQL pré et post migration me semble très bien. Cela laisserait plus liberté et éviterait de rendre TaxHub dépendant de tables extérieures au schéma taxonomie.

Je viens de me rendre compte que dans les anciennes versions du script de migration, il était possible d'utiliser un script SQL supplémentaire 4.3_restore_local_constraints.sql qui permettait justement de gérer ce problème.
Il semble avoir disparu avec l'intégration du script à Flask.