[OCCTAX] - dénombrement qui switch d'occurrence

[jbrieuclp]

Version
2.14

Description du bug
Salut,
Je continue d'avoir des dénombrements qui switchent d'occurrences :

• Une saisie d'une occurrence (o1) + denombrement (d1) : log insert pour o1 et d1 dans la table gn_commons.t_history_actions
• Modif des info de o1 : log de modif de o1 en (U) dans gn_commons.t_history_actions pas de log pour d1 (???)
• Ajout d'une nouvelle occurrence (o2) : log d'ajout de o2 associé à la modif de d1 qui prend le nouvel id_occurence_occtax de d2

Du coup o1 n'a plus de dénombrement associé et n'est donc plus présent en synthèse

Comment reproduire
Aucune idée et c'est bien ça le problème !..

[jbrieuclp]

Salut, on reste solo à avoir des dénombrements qui switchent d'occurrences ?
48 cas depuis le post du 25 juillet !
Il suffit de vérifier en base s'il existe des occurrences qui ne sont plus associées à un dénombrement :

SELECT count(*) -- ou juste *
FROM pr_occtax.t_occurrences_occtax o
WHERE NOT EXISTS (SELECT NULL FROM pr_occtax.cor_counting_occtax c WHERE o.id_occurrence_occtax = c.id_occurrence_occtax);

[Splendens]

Salut,

J'ai lancé la requête sur plusieurs BD GeoNature, et effectivement, il y en a toujours une poignée qui ressort !

[jbrieuclp]

J'ai fouillé depuis cette aprem le pourquoi du comment sans trouver de truc flagrant. Il y aurait encore des choses à revoir/cleaner concernant les appels et reprises de variables dans les services du module occtax (et aussi des autres modules)
Ici :

GeoNature/contrib/occtax/frontend/app/occtax-form/counting/counting.component.ts

Lines 54 to 64 in 3bdda83

	ngOnDestroy() {
	//delete elem from form.get('cor_counting_occtax')
	const idx = (
	this.occtaxFormOccurrenceService.form.get('cor_counting_occtax') as UntypedFormArray
	).controls.findIndex((elem) => elem === this.form);
	if (idx !== -1) {
	(
	this.occtaxFormOccurrenceService.form.get('cor_counting_occtax') as UntypedFormArray
	).removeAt(idx);
	}
	}

Si on commente la ligne 61-62 le problème est reproduit.
Donc il faut fouiller du côté du .findIndex((elem) => elem === this.form) qui ne retourne aucun résultat.
Comparer 2 objets aussi complexe qu'un formulaire en simple équivalence JS (===) est osé, même avec lodash ce n'est pas certain que ca passe...

[DonovanMaillard]

Je confirme le comportement aussi sur notre instance, quelques items corrigés en septembre. Ca apparait quand on modifie une occurrence à priori, au lieu de la modifier, ca en crée une nouvelle. Le dénombrement reste sur l'ancienne occurrence et la nouvelle n'en a pas, ou inversement à priori.

[jbrieuclp]

J'ai trouvé comment reproduire !! Et je l'ai fait sur la demo...
Lors d'une modification d'une données existante : il faut faire 2 modifications sur un élément du formulaire du dénombrement (j'ai l'impression qu'il faut quitter le focus entre 2 actions, mais pas forcément pour le stade de vie et le dénombrement ou alors il faut un petit délais entre les changements, ce n'est pas encore clair à ce niveau là) après l'enregistrement des modifications, le bouton "Enregistrer ce taxon" redevient actif alors même que le formulaire de saisie est vide.
Là 2 possibilités :

• cliquer sur enregistrer sans mettre de taxon, dans ce cas ca créer une seconde ligne avec le même taxon et vampirise le dénombrement du premier ;
• saisir un second taxon qui va vampiriser le dénombrement du premier.
  Il faut refresh la page pour refresh aussi la liste des taxons enregistrer et voir le dénombrement à 0.

Je vais poursuivre mes investigations pour trouver ce qui cause ce problème.

[pnrnm-sig]

Bien vu ! On a le même problème, et j'arrivais pas à le reproduire non plus. Pour le moment j'ai demandé aux utilisateurs de ré éditer les relevés avec un problème, en repérant les relevés et les taxons mélangés

-- occurence sans dénombrement
select * from pr_occtax.t_occurrences_occtax too
left join pr_occtax.cor_counting_occtax cco on cco.id_occurrence_occtax = too.id_occurrence_occtax
left join gn_synthese.synthese s on s.unique_id_sinp = cco.unique_id_sinp_occtax
where cco.id_counting_occtax is null

-- observation qui ne correspondent pas / relevé avec dénombrement qui correspond à un autre taxon
select too.id_releve_occtax, too.cd_nom,too.nom_cite,s.cd_nom,s.nom_cite, s.meta_create_date, s.meta_update_date from gn_synthese.synthese s
join pr_occtax.t_releves_occtax tro on tro.unique_id_sinp_grp = s.unique_id_sinp_grp
left join pr_occtax.cor_counting_occtax cco on cco.unique_id_sinp_occtax = s.unique_id_sinp
left join pr_occtax.t_occurrences_occtax too on too.id_occurrence_occtax = cco.id_occurrence_occtax
where too.cd_nom != s.cd_nom
order by too.id_releve_occtax asc

[jbrieuclp]

Salut

Cette requête permet de reconstruire les données qui ont disparues au format de la table cor_counting_occtax:

SELECT t.table_content->>'id_occurrence_occtax', t.table_content->>'id_nomenclature_life_stage', t.table_content->>'id_nomenclature_sex', t.table_content->>'id_nomenclature_obj_count', t.table_content->>'id_nomenclature_type_count', t.table_content->>'count_min', t.table_content->>'count_max', t.table_content->>'additional_fields'
FROM (
select DISTINCT ON (d1.uuid_attached_row) d1.uuid_attached_row, d1.*
from pr_occtax.t_occurrences_occtax o
INNER JOIN gn_commons.t_history_actions o1 ON o.unique_id_occurence_occtax = o1.uuid_attached_row
INNER JOIN gn_commons.t_history_actions d1 ON d1.table_content->>'id_occurrence_occtax' = o1.table_content->>'id_occurrence_occtax'
INNER JOIN gn_commons.t_history_actions d2 ON d2.uuid_attached_row = d1.uuid_attached_row  
INNER JOIN gn_commons.t_history_actions o2 ON d2.table_content->>'id_occurrence_occtax' = o2.table_content->>'id_occurrence_occtax'
WHERE 
	NOT EXISTS (SELECT NULL FROM pr_occtax.cor_counting_occtax c WHERE o.id_occurrence_occtax = c.id_occurrence_occtax)
	AND o1.id_table_location = 3 -- ID table t_occurrence_occtax
	AND d1.id_table_location = 2 -- ID table cor_counting_occtax
	AND d2.id_table_location = 2 -- ID table cor_counting_occtax
	AND o2.id_table_location = 3 AND o2.operation_type = 'I' -- table t_occurrence_occtax
	AND d2.table_content->>'id_occurrence_occtax' <> d1.table_content->>'id_occurrence_occtax'
	-- AND o1.table_content->>'id_releve_occtax' = '541160'
ORDER BY d1.uuid_attached_row, d1.operation_date DESC
) as t

Il te faut peut-être réadapter les ID de table selon ce que tu as dans ta table gn_commons.bib_tables_location.

Passes par les producteurs pour vérifier le résultat...
Et si ton résultat est bon tu peux l'utiliser pour faire un INSERT (INSERT INTO pr_occtax.cor_counting_occtax (id_occurrence_occtax, id_nomenclature_life_stage, id_nomenclature_sex, id_nomenclature_obj_count, id_nomenclature_type_count, count_min, count_max, additional_fields)) et restaurer les données.

[camillemonchicourt]

OK merci pour les requêtes.
Si la requêtes de récupération des données est validée, alors il faudra l'ajouter dans la PR qui corrige le soucis de saisie.

[jbrieuclp]

C'est bien ce que je me suis dis en la postant ici...
De mon côté elle fonctionne et corrige. Après si quelqu'un peut confirmer sa validité sur une autre base ce serait mieux.

[pnrnm-sig]

J'ai testé de mon côté (geonature 2.14.2), et ça fonctionne aussi. J'ai modifié les numéros de table comme indiqué et aussi ajouté des CAST parce que les types n'étaient pas bon pour l'INSERT.

INSERT INTO pr_occtax.cor_counting_occtax (id_occurrence_occtax, id_nomenclature_life_stage, id_nomenclature_sex, id_nomenclature_obj_count, 
id_nomenclature_type_count, count_min, count_max, additional_fields)

SELECT 
	CAST(t.table_content->>'id_occurrence_occtax' as BIGINT) as id_occurrence_occtax, 
	CAST(t.table_content->>'id_nomenclature_life_stage' as INT) as id_nomenclature_life_stage, 
	CAST(t.table_content->>'id_nomenclature_sex' as INT) as id_nomenclature_sex, 
	CAST(t.table_content->>'id_nomenclature_obj_count' as INT) as id_nomenclature_obj_count, 
	CAST(t.table_content->>'id_nomenclature_type_count' as INT) as id_nomenclature_type_count, 
	CAST(t.table_content->>'count_min' as INT) as count_min, 
	CAST(t.table_content->>'count_max' as INT) as count_max, 
	CAST(t.table_content->>'additional_fields' as JSON) as additional_fields
FROM (
select DISTINCT ON (d1.uuid_attached_row) d1.uuid_attached_row, d1.*
from pr_occtax.t_occurrences_occtax o
INNER JOIN gn_commons.t_history_actions o1 ON o.unique_id_occurence_occtax = o1.uuid_attached_row
INNER JOIN gn_commons.t_history_actions d1 ON d1.table_content->>'id_occurrence_occtax' = o1.table_content->>'id_occurrence_occtax'
INNER JOIN gn_commons.t_history_actions d2 ON d2.uuid_attached_row = d1.uuid_attached_row  
INNER JOIN gn_commons.t_history_actions o2 ON d2.table_content->>'id_occurrence_occtax' = o2.table_content->>'id_occurrence_occtax'
WHERE 
	NOT EXISTS (SELECT NULL FROM pr_occtax.cor_counting_occtax c WHERE o.id_occurrence_occtax = c.id_occurrence_occtax)
	AND o1.id_table_location = 5 -- ID table t_occurrence_occtax
	AND d1.id_table_location = 4 -- ID table cor_counting_occtax
	AND d2.id_table_location = 4 -- ID table cor_counting_occtax
	AND o2.id_table_location = 5 AND o2.operation_type = 'I' -- table t_occurrence_occtax
	AND d2.table_content->>'id_occurrence_occtax' <> d1.table_content->>'id_occurrence_occtax'
	--AND o1.table_content->>'id_releve_occtax' = '31681'
ORDER BY d1.uuid_attached_row, d1.operation_date DESC
) as t
;

Si j'ai des retours négatifs des producteurs je vous dirai. Merci !

[PaulLabruyere]

Bonjour tout le monde !

Je me suis rendu compte la semaine dernière qu'on avait ce bug dans Clicnat, avec une dizaine d'occurrences impactées... Merci infiniement pour les queries qui ont permis de rattrapper le coup facilement 🙇 à vue de nez tout à l'air en ordre, j'ai contacté les producteurs des données pour que chacun vérifie les siennes.

En revanche, une des obs remontée semble un peu différente des autres... en creusant un peu, je me rend compte qu'on a potentiellement le même pb à l'échelle du relevé 😱

J'ai sorti toutes les entrées de la table gn_commons.t_history_actions relatives aux relevés, occurrences et dénombrements associés à ce cas de figure : history_variant_3139.csv

On voit qu'à 10h07, un relevé est créé. Ensuite, l'utilisatreur ajoute ses taxons noramelement, on voit des couples création occurrence / création dénombrement aux mêmes secondes jusque 10h12.

À 10h15, un nouveau relevé est créé avec des infos identiques, seule la localisation présente un écart de 2,5 cm, potentiellement une différence d'arrondi. Par la suite, chaque fois qu'une occurrence est créée, au lieu d'ajouter un dénombrement, c'est le dernier dénombrement créé dans le premier relevé qui change d'occurrence.

Ce genre de cas est masqué dans la query par le distinct on (d1.uuid_attached_row) vu que c'est toujours la même ligne qui est modifiée. Si on change pour distinct on (d1.uuid_attached_row, d1.operation_date) on retrouve les différents changements, mais attention car je ne suis pas sur qu'on puisse toujours revenir à l'état souhaitable dans ce cas là avec la query, potentiellement le dénombrement décrit dans d1.table_content est toujours le même.

Peut être un nouveau variant du bug 3139 ? 😷 J'ai contacté la perosnne qui a saisi relevé pour savoir si elle se souvient de ce qui s'est passé ce jour là.