TaxHub
TaxHub copied to clipboard
Release 1.11.2 non compatible avec GN 2.12.3 ou inférieur
J'ai MAJ ce WE une instance avec GN 2.12.3 et le dernier Taxhub 1.11.2 et ça lève une erreur
psycopg2.errors.UndefinedColumn: ERREUR: la colonne vm_taxref_list_forautocomplete.unaccent_search_name n'existe pas
LINE 1: ...nomie_vm_taxref_list_forautocomplete_search_name, taxonomie....
Cette erreur se produit dans occtax lors de l'appel de la route taxhub/api/taxref/allnamebylist
Cette dernière version 1.12.2 fonctionne avec une révison de la base qui ajoute une colonne unaccent_search_name
dans la vue matérialisée vm_taxref_list_forautocomplete
: https://github.com/PnX-SI/TaxHub/blob/5c5354ffedc8b4242ae7d69d01bc3ba3ba19033a/apptax/migrations/versions/3bd542b72955_optimize_vm_taxref_for_autocomplete.py#L27
GeoNature utilise cette route de l'api de taxhub mais sa base n'est pas à jour. En effet, comme GeoNature 2.12.3 a été publiée avant taxhub 1.11.2 le requirement.txt de cette version de GeoNature appelle taxhub 1.11.1 dans son requirement.txt, . La révision alembic qui modifie la vm_taxref_list_forautocomplete
pour créer la colonne manquante n'est donc pas appellée lors de la mise à jour de la base par l'alembic de GeoNature.
Du coup pour utiliser taxhub 1.11.2, il faudrait publier une nouvelle release de GeoNature et/ou signaler que cette release 1.11.2 de Taxhub n'est pas compatble avec GeoNature 2.12.3 ou inférieur. OU modifier manuellement le requirement.txt de GeoNature avant de lancer le fichier migration.sh de GeoNature.
Bonjour,
Oui effectivement, tu as tout bon. J'ai dû rajouter cette colonne à la vue et comme geonature gère les migrations de tous les modules et les apps, il se retrouve incompatible.
Donc il faudrait avertir les utilisateurs qu'il ne faut pas mettre à jour TaxHub indépendamment de GeoNature et de se fier à la version utilisée dans les requirements qui est la 1.11.1 comme tu l'as dit.
A tester si cela fonctionne bien de mettre à jour dans les requirements. Si c'est le cas, comme discuté avec @camillemonchicourt, on pourra faire une release de GeoNature pour bump de cette dépendance.
Désolé pour ce problème en tout cas, je n'avais pas anticipé ce souci de requirements...
Si vous pouvez mettre à jour les notes de versions sur les dernières releases de GeoNature et Taxhub ça serait top.
J'ai contourné le soucis en jouant manuellement le sql de mise à jour de vm_taxref_list_forautocomplete
pioché dans le fichier TaxHub/apptax/migrations/versions/3bd542b72955_optimize_vm_taxref_for_autocomplete.py
Tout à l'air de fonctionner normalement. J'espère que je n'aurai pas de souci lors de la prochaine mise à jour avec Alembic en ayant modifié la base manuellement. Mais vue que cette révision Alembic drop la vm pour la recréer, ça ne devrait pas poser de pb. Tu confirmes ?
A tester si cela fonctionne bien de mettre à jour dans les requirements. Si c'est le cas, comme discuté avec @camillemonchicourt, on pourra faire une release de GeoNature pour bump de cette dépendance.
De ce que j'ai compris d'une récente discussion avec @amandine-sahl, ça devrait le faire. Alembic va chercher les révisions taxhub à passer en fonction de ce qu'il y a dans les requirements. Et elle m'a déconseillé de jouer un db autoupgrade avec la commande flask depuis le virtual env de Taxhub. Si Taxhub ne vit pas tout seul et que Geonature est utilisé, c'est toujours depuis GN qu'il faut le faire.
Et l'optimisation de l'autocomplete me semble très efficace :+1: Merci.
Oui il y avait cette solution ou la première solution pure SQL que j'avais proposée ici : https://github.com/PnX-SI/TaxHub/issues/384 Et comme il y a juste modification de la VM et des index liés, un DROP de la VM supprimera aussi les index. Par contre cette solution introduit une nouvelle fonction SQL dans public...
Sinon pour la solution que tu as choisie, oui la migration fait un DROP avant donc aucun problème. Le souci viendra peut-être de la synthèse (je viens de m'apercevoir qu'on n'a pas prévu de rapatrier cette optimisation ici) car la route de recherche de taxon (https://github.com/PnX-SI/GeoNature/blob/2c3b17f7e2bdbf2cd23c8d2be52c7b47b5ad4baf/backend/geonature/core/gn_synthese/routes.py#L793) se base sur ce modèle : https://github.com/PnX-SI/TaxHub/blob/5c5354ffedc8b4242ae7d69d01bc3ba3ba19033a/apptax/taxonomie/models.py#L227 A voir si ça pose problème...
A tester si cela fonctionne bien de mettre à jour dans les requirements. Si c'est le cas, comme discuté avec @camillemonchicourt, on pourra faire une release de GeoNature pour bump de cette dépendance.
Tester lors d'un passage de GN 2.11.2 à 2.12.3 en mettant taxhub==1.11.3
au lieu de taxhub==1.11.1
dans backend/requirements.txt
, la migration passe sans souci.