Project

General

Profile

Bug #25982

rendre les identifiants stables sinon les visualisation ne peuvent pointer sur des valeurs

Added by Serghei Mihai 11 months ago. Updated 4 months ago.

Status:
Fermé
Priority:
Normal
Target version:
-
Start date:
31 Aug 2018
Due date:
% Done:

0%

Patch proposed:
Yes
Planning:
No

Description

Car les identifiants, séquentiels, sont générés au fur et à mesure de la réception des données depuis wcs. Et donc l'ordre peut être différent.

Lors du calcul des stats faire la résolution "label" -> "id".

0001-reuse-older-id-for-open-item-fields-fixes-25982.patch View (1.89 KB) Benjamin Dauvergne, 18 Oct 2018 06:05 PM

0001-reuse-older-id-for-open-item-fields-fixes-25982.patch View (1.39 KB) Benjamin Dauvergne, 18 Oct 2018 06:18 PM


Related issues

Related to OLAP / Businesse Intelligence pour Publik - Development #30752: Conserver les donnés des tables de dimensions Solution déployée 19 Feb 2019

History

#1 Updated by Benjamin Dauvergne 11 months ago

Oui, pour les ItemField (choix fermés) dont on a pas la visibilité de l'ensemble, en fait uniquement ceux avec une source JSONP, on accumule les valeurs au fur et à mesure du chargement et on génère un id numérique, l'ordre peut donc varier et donc les ids. Pour les types JSON, formule ou liste explicite c'est moins fréquent parce qu'on a l'ensemble des choix exportés dans le schéma du formulaire mais on aura aussi un problème en cas de changement de la liste.

La bonne solution comme le suggère subtilement Serghei ce serait de stocker le label en plus de l'id dans le stockage de la visualisation et chercher le label au dernier moment au lieu d'utiliser l'id si c'est possible (en cas de suppression d'une valeur on aura encore un souci mais là on y peut rien).

#2 Updated by Emmanuel Cazenave 11 months ago

  • Assignee set to Emmanuel Cazenave

#3 Updated by Thomas Noël 11 months ago

Benjamin Dauvergne a écrit :

Pour les types JSON, formule ou liste explicite c'est moins fréquent parce qu'on a l'ensemble des choix exportés dans le schéma du formulaire mais on aura aussi un problème en cas de changement de la liste.

Et en réalité c'est assez fréquent car il faut compter sur les JSON qui sont dépendants d'une variable précédente dans le formulaire, genre « la liste des quartiers de la ville {{form_var_ville}} ». Je dis ça juste pour faire mon intéressant dans le ticket, la solution subtile de Serghei est la bonne.

#5 Updated by Emmanuel Cazenave 11 months ago

  • Status changed from Nouveau to En cours

#6 Updated by Emmanuel Cazenave 10 months ago

  • Assignee deleted (Emmanuel Cazenave)
  • Status changed from En cours to Nouveau

#8 Updated by Emmanuel Cazenave 10 months ago

  • Assignee set to Emmanuel Cazenave

#9 Updated by Benjamin Dauvergne 9 months ago

#10 Updated by Benjamin Dauvergne 9 months ago

  • Status changed from Solution proposée to En cours

Ne marche pas si les valeurs n'arrivent pas dans le bon ordre1, il faut plutôt récupérer totalement l'ancienne lors de la création de la table.

1 Ancienne table

id value
1 a
2 b
3 c

Nouvelles valeurs dans leur ordre d'arrivé: a, c, d, c, donnant la table:

id value
1 a
2 b
3 c

ici erreur lors de l'insertion de (3, c) repris de l'ancienne table.

#11 Updated by Benjamin Dauvergne 9 months ago

Nouvelle solution, a la creation d'une table pour un "open item field" on importe la table du précédent schéma (dont les valeurs ne disparaîtront donc plus).

#12 Updated by Benjamin Dauvergne 9 months ago

  • Subject changed from dans les visualisations utiliser les libellé des champs filtres au lieu des identifiants to rendre les identifiants stables sinon les visualisation ne peuvent pointer sur des valeurs

#13 Updated by Benjamin Dauvergne 9 months ago

  • Project changed from BiJoe to OLAP / Businesse Intelligence pour Publik

Le problème semble aussi présent sur les tables de formulaires voir #27529.

#15 Updated by Benjamin Dauvergne 9 months ago

  • Status changed from Solution proposée to En cours

#16 Updated by Benjamin Dauvergne 9 months ago

Bouh c'est plus compliqué que prévu, garder des valeurs de formdef pour des formdef qui n'existent plus et dont la table aura disparu c'est embêtant (jusqu'à ce qu'on sache gérer de l'incrémental).

Il faudrait:
  • pour les formdef et les agents utiliser un identifiant stable (on a id pour les agents, pour les formdefs id+slug je dirait, le premier pouvant être réutiliser il me semble, mais le deuxième pouvant changer :/)
  • pour les valeurs des options peut-être garder le plan initiale de conserver dans la visualisation le label et non la valeur...

#17 Updated by Serghei Mihai 8 months ago

Je serai pour ici gérer uniquement la cohérence des libellés et valeurs dans les visualisations.

Le cas des formdefs inexistants peut-être géré séparemment, dans #27412 par exemple.

#18 Updated by Serghei Mihai 6 months ago

  1. take old id, value paris an inject them <--- s/paris/paris/

et

selx.ex('SELECT SETVAL...

il faut un self.ex

#19 Updated by Benjamin Dauvergne 6 months ago

Non mais de toute façon je ne suis pas content de cette solution... Le seul chemin viable pour moi c'est de modifier complètement les identifiants mais je ne vois pas comment en même modifier les visualisations parce que la modification sera faite dans wcs-olap et pas dans bijoe et je ne vois pas comment faire une migration dans bijoe pour cela...

Un plan en plusieurs temps :
1. ajouter les identifiants naturels au tables coté wcs-olap sans rien changer d'autres
2. quand tout ça est à jour, passer une migration manuelle sur les instances bijoe qui viendra modifier les visualisation pour utiliser cette identifiant plutôt que la clé primaire de postgres
3. modifier le schéma généré par wcs-olap pour utiliser cette valeur la jointure plutôt que la clé primaire

#20 Updated by Serghei Mihai 6 months ago

Du coup on fait des tickets séparés: une créer des identifiants naturels, et un autre pour faire la migration et modifier les schéma?

#21 Updated by Benjamin Dauvergne 6 months ago

Serghei Mihai a écrit :

Du coup on fait des tickets séparés: une créer des identifiants naturels, et un autre pour faire la migration et modifier les schéma?

On peut faire le point 1 dans ce ticket:
  • identifiants stables pour les agents
  • les rôles
  • les fonctions
  • les statuts
  • les items (soit l'id pour une source de donnée, soit le libellé)

On aura des tables id,source_id,label et pour l'instant source_id sera inutilisé par BiJoe, sans modifier le schéma il continuera à utiliser id, pour pas se faire chier je propose que source_id soit toujours varchar et quand on a un identifiant numérique on fait juste appel à str().

#22 Updated by Benjamin Dauvergne 6 months ago

  • Assignee deleted (Emmanuel Cazenave)

J'enlève Manu comme assigné, je ne sais pas qui va s'en occuper.

#23 Updated by Emmanuel Cazenave 5 months ago

  • Assignee set to Emmanuel Cazenave

#24 Updated by Benjamin Dauvergne 5 months ago

Discussion à l'instant avec manu, plan en 2,5 temps :
  • pour chaque table de label, refaire la mécanique pour prendre la table dans l'ancien schéma, insérer la totalité des valeurs dans la nouvelle table et poser le générateur de séquence comme le max des id existants (pour les nouvelles valeurs), voir si on préfère conserver la totalité des anciennes valeurs ou ne garder que celle existant vraiment dans le nouveau schéma
  • préparer l'avenir en ajoutant aux tables de label une colonne natural_id varchar dans laquelle on mettra :
    • pour les formdef, formdef.id
    • pour les category, category.id
    • pour les items field "naturels", le label de l'item
    • pour les items field venant de source de données form_var_<varname>_raw (l'id naturel venant de la source de donnée)
    • pour les agents le NameID
    • pour les rôles, le slug, si pas de slug on ignore (ça ne doit pas arriver)
    • pour les canaux, le slug (le label en fait) : web, mail, etc..
    • pour les statuts simplifiés, rien, id totalement contrôlé par wcs-olap pas de souci
À la fin ouvrir un nouveau ticket pour la migration conjointe entre wcs-olap et bijoe des ids générés vers les natural_id:
  • coté wcs-olap changer tous les 'type': 'integer', 'value': '"field_x.id"' en 'type': 'string', 'value': '"field_x.natural_id"'
  • coté bijoe dans toutes les visualisations chercher les filtrages dans toutes les visualisation et quand on trouve une valeur entière la remplacer par le natural_id qui correspond en regardant dans la table concernée:
    • for x in filters: puis trouver la table formdata_y_field_x correspondante, cherche l'id dans la colonne id et recopier le natural_id

#25 Updated by Serghei Mihai 5 months ago

Benjamin Dauvergne a écrit :

Discussion à l'instant avec manu, plan en 2,5 temps :
  • pour chaque table de label, refaire la mécanique pour prendre la table dans l'ancien schéma, insérer la totalité des valeurs dans la nouvelle table et poser le générateur de séquence comme le max des id existants (pour les nouvelles valeurs), voir si on préfère conserver la totalité des anciennes valeurs ou ne garder que celle existant vraiment dans le nouveau schéma

Je suis d'avis de garder toutes les valeurs même si elles n'existent pas. Et cela pour ne pas casser les visualisations sauvegardées avec ces libellés.

#26 Updated by Benjamin Dauvergne 5 months ago

Serghei Mihai a écrit :

Benjamin Dauvergne a écrit :

Discussion à l'instant avec manu, plan en 2,5 temps :
  • pour chaque table de label, refaire la mécanique pour prendre la table dans l'ancien schéma, insérer la totalité des valeurs dans la nouvelle table et poser le générateur de séquence comme le max des id existants (pour les nouvelles valeurs), voir si on préfère conserver la totalité des anciennes valeurs ou ne garder que celle existant vraiment dans le nouveau schéma

Je suis d'avis de garder toutes les valeurs même si elles n'existent pas. Et cela pour ne pas casser les visualisations sauvegardées avec ces libellés.

Mouais, faudra voir, peut-être ajouter une colonne alive booléenne pour noter si la valeur vient d'avant ou est encore utilisée, juste pour se souvenir qu'on y pense.

#27 Updated by Emmanuel Cazenave 5 months ago

#28 Updated by Emmanuel Cazenave 4 months ago

  • Status changed from En cours to Fermé

Les choses se sont passées ici : #30752, la suite se passera là #31315.

Also available in: Atom PDF