Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release 1.11.2 non compatible avec GN 2.12.3 ou inférieur #396

Open
gildeluermoz opened this issue Jun 5, 2023 · 4 comments
Open

Release 1.11.2 non compatible avec GN 2.12.3 ou inférieur #396

gildeluermoz opened this issue Jun 5, 2023 · 4 comments

Comments

@gildeluermoz
Copy link
Contributor

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 :

unaccent(t.search_name) AS unaccent_search_name,

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.

@mvergez
Copy link
Contributor

mvergez commented Jun 5, 2023

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...

@gildeluermoz
Copy link
Contributor Author

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 👍 Merci.

@mvergez
Copy link
Contributor

mvergez commented Jun 5, 2023

Oui il y avait cette solution ou la première solution pure SQL que j'avais proposée ici : #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 :

class VMTaxrefListForautocomplete(db.Model):

A voir si ça pose problème...

@gildeluermoz
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants