search

PnX-SI / GeoNature

Application de saisie et de synthèse des observations faune et flore
GNU General Public License v3.0
100 stars 102 forks source link

[GN 2.11] Modification du nombre d'occurrence d'une obs et contrainte « check_cor_counting_occtax_count_max » #2385

Open JeromeMaruejouls opened 1 year ago

JeromeMaruejouls commented 1 year ago

Dans la version 2.11, j'ai une erreur lors de la modification du nombre d'occurrence d'une obs dans OccTax :

Dans les log : "la nouvelle ligne de la relation « cor_counting_occtax » viole la contrainte de vérification « check_cor_counting_occtax_count_max »" et on voit dans la requête que la valeur max n'est pas mise à jour (donc on essaie d'enregistrer dans la base une obs avec le min>max

Avez vous le même comportement ? (contournable actuellement en augmentant le min puis le max)

JeromeMaruejouls commented 1 year ago

A noter que je viens de tester sur le serveur Démo et que le problème n'appartait pas... C'est donc soit un problème introduit entre la 2.11.0 (serveur démo) et la 2.11.2 (chez moi), soit un problème spécifique à mon installation.

DonovanMaillard commented 1 year ago

Bonjour,

Je viens de tester sur ma 2.11.2 en prod. Je n'ai pas le soucis, passer de 1/1 à 2/2 puis de 2/2 à 3/3 ne pose pas de soucis de mon coté.

JeromeMaruejouls commented 1 year ago

Merci du retour. Je vais regarder mieux de mon coté ce qui pourrait bloquer.

JeromeMaruejouls commented 1 year ago

J'ai en fait exactement le même problème que là : https://github.com/PnX-SI/GeoNature/issues/1479#issuecomment-1282038337

@Splendens : tu parles d'une histoire de cache pour résoudre le problème... tu te rappelles un peu mieux ce que tu avais fait ?

Dans les log, on voit cette requete : [SQL: UPDATE pr_occtax.cor_counting_occtax SET count_min=%(count_min)s, additional_fields=%(additional_fields)s WHERE pr_occtax.cor_counting_occtax.id_counting_occtax = %(pr_occtax_cor_counting_occtax_id_counting_occtax)s]

et j'ai donc l'impression que l'appli essaie de modifier simplement le min dans la base de donnée, ce qui entraine l'erreur de min>max.

Splendens commented 1 year ago

Je pense que j'ai dû supprimer tout le cache du navigateur. Sinon, pour vérifier si ça vient du cache ou pas, tu peux essayer la modification des min et max qui crée l'erreur dans une fenêtre de navigation privée peut-être ?

JeromeMaruejouls commented 1 year ago

Je pense que j'ai dû supprimer tout le cache du navigateur. Sinon, pour vérifier si ça vient du cache ou pas, tu peux essayer la modification des min et max qui crée l'erreur dans une fenêtre de navigation privée peut-être ?

Non, ce n'est pas une question de cache de mon coté. Ce qui est bizarre, c'est que j'ai deux serveurs (un test et un prod) avec la même conf et quasiment la même base de donnée (test à une sauvegarde récente de la prod) et ca fonctionne sur le serveur test et pas sur celui de prod ...

DonovanMaillard commented 1 year ago

Bonjour,

Malgré mon retour de la derniere fois, mon collegue vient de m'indiquer qu'il avait bien le soucis aussi sur la même instance (?!). J'ai pu reproduire à l'instant en effet ... assez surprenant donc.

JeromeMaruejouls commented 1 year ago

Est ce que ca ne serait pas un problème lié au front qui n'enverrai pas les changements les deux champs (min et max) dans tous les cas ? (supposition, je ne connais pas du tout le fonctionnement prévu)

DonovanMaillard commented 1 year ago

oui oui ca semble bien un truc comme ca, le champs max est automatiquement mis à jour en interface mais pas pris en compte au niveau du post...

par contre c'est bizarre que j'ai pu reproduire ce matin et pas l'autre jour. Je vais retourner sur mon autre ordi (utilisé la derniere fois), pour voir si je peux reproduire ou non... a voir s'il y a pas un soucis qui dépend du navigateur (??)

camillemonchicourt commented 1 year ago

Ah mais ça c'est bien corrigé dans la 2.12.0. Vous confirmez ?

JeromeMaruejouls commented 1 year ago

Pas eu le temps de faire l'update encore. Je te tiens au courant ASAP.

JeromeMaruejouls commented 1 year ago

Je viens d'installer la 2.12.2 et problème toujours présent : seul le min est envoyé dans la requete POST ce qui entraine un min > max en base et bloque l'update. Il faudrait réouvrir ce ticket. Merci.

TheoLechemia commented 1 year ago

Je ne reproduit toujours pas ... On est d'accord que tu pars d'un dénombrement ou min = 1 et max = 1 et que tu passes les deux à 2 ? (où il suffit de modifier le count_min de 1 à 2, car le max est synchronisé tout seul par l'UI)

JeromeMaruejouls commented 1 year ago

Je viens de tester à l'instant : aucun problème pour passer de 1 à 1, mais par contre, j'ai eu le problème en redescendant de 2,2 à 1,1... Concernant l'UI, quand je monte le min, le max monte aussi normalement et pareil quand je baisse le max. Voici les log :

sqlalchemy.exc.IntegrityError: (raised as a result of Query-invoked autoflush; consider using a session.no_autoflush block if this flush is occurring prematurely)
(psycopg2.errors.CheckViolation) ERREUR:  la nouvelle ligne de la relation « cor_counting_occtax » viole la contrainte de vérification « check_cor_counting_occtax_count_max »
DETAIL:  La ligne en échec contient (276076, 84e3259c-4bf9-485c-8339-f36aec181d79, 272509, 1, 172, 147, 95, 2, 1, {})

[SQL: UPDATE pr_occtax.cor_counting_occtax SET count_max=%(count_max)s WHERE pr_occtax.cor_counting_occtax.id_counting_occtax = %(pr_occtax_cor_counting_occtax_id_counting_occtax)s]
[parameters: {'count_max': 1, 'pr_occtax_cor_counting_occtax_id_counting_occtax': 276076}]
(Background on this error at: http://sqlalche.me/e/13/gkpj)
camillemonchicourt commented 1 year ago

Après différents tests où on ne reproduisait pas, on vient enfin de reproduire. Le problème arrive donc de manière irrégulière et aléatoire, et on pense avoir compris pourquoi. Le soucis ne vient pas du frontend qui poste bien ce qu'il faut.

Le soucis vient du backend. On lui poste tout le contenu du dénombrement mais il semble la traiter par morceau et pas toujours dans le même ordre. Et donc si on passe de 2;2 à 1;1 et que le backend essaie d'abord de passer le max de 2 à 1, alors la contrainte de la BDD bloque la requête, ce qui est "normal".

A voir si on peut faire en sorte que SQLAlchemy exécute la requête en une seule fois.

JeromeMaruejouls commented 1 year ago

De ce que je comprends, il décompose la requête dans une transaction. Il faudrait que le Check ne soit vérifié qu'au Commit de la transaction (DEFERRED). Mais apparemment, ce n'est pas possible dans PostgreSQL pour ce type de contrainte. Il faudrait donc modifier le code Python pour forcer la modification du min et du max dans une même requete et non une même transaction.

bouttier commented 1 year ago

C’est du marshmallow, alors on ne maitrise pas forcément très bien à quel moment les updates sont fait. En théorie sqlalchemy devrait émettre un seul update, à moins qu’il y a un flush entre temps. Je me demande d’où vient le fait qu’il y a deux requêtes update du coup …

bouttier commented 1 year ago

Peut-être que with db.session.no_autoflush peut aider