Produits Entr'ouvert » OLAP / Business Intelligence pour Publik

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

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.

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

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

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.

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

et

selx.ex('SELECT SETVAL...

il faut un self.ex

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

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?

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?

• 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().

• 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

• 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

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.

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.