Produits Entr'ouvert » OLAP / Business Intelligence pour Publik

C'est loin d'être évident, c'est exactement le même problème que #25982 qui a été fermé sans ouvrir de ticket pour continuer (on pourrait prendre celui-ci en le renommant): si on change les valeurs de filtrage on va casser toutes les visualisations actuelles qui utilisent ces valeurs.

• faire évoluer wcs-olap pour avoir cette valeur stable et l'utiliser partout à la place des id (ça veut dire plus de dimension comme

                  {
                      'name': 'formdef',
                      'label': 'formulaire',
                      'join': ['formdef'],
                      'type': 'integer',
                      'value': 'formdef.id',
                      'value_label': 'formdef.label',
                      'order_by': 'formdef.label',
                  },
  

  
  où on a 'value' == '<jointure>.id', mais plutôt :
  

                  {
                      'name': 'formdef',
                      'label': 'formulaire',
                      'join': ['formdef'],
                      'type': 'integer',
                      'value': 'formdef.slug',
                      'value_label': 'formdef.label',
                      'order_by': 'formdef.label',
                  },
  

  
  ça restera bancal en cas de changement de slug mais c'est quand même moins fréquent (et si on expose les visu dans l'admin Django on pourra toujours aller corriger assez simplement)
• ensuite faire une migration coté bijoe qui aurait cette tête (et je ne pense pas une migration Django plutôt un script) :
  • parcourir l'ensemble des visualisations,
    • trouver les valeurs des filtrages (des trucs genre @[1,2,3],
    • remplacer les id (c'est forcément des entiers) par la nouvelle valeur, via :
      • prendre la dimension correspondant au filtre, parser 'value' en extraire la jointure (si pas jointure on est bon), on peut se baser sur join éventuellement (si y en a qu'une seule ça devrait aller sinon c'est plus compliqué)
      • chercher la ligne <jointure>.id dans la table,
      • calculer 'value' pour cette ligne, ça donne la nouvelle valeur

Pour revenir au souci de Arles (je vais copier mon laïus dans un autre ticket finalement); il faut stabiliser les ids comme on l'a fait pour les items, i.e. reprendre la table précédente, et oui il faudra les slugs puisque les labels ne sont pas stables.

• id : serial
• ref : text
• label : text

ref étant le truc stable à utiliser pour récupérer les anciens id dans la table précédente, après création on poserait le curseur de séquence sur le max(id) de l'ancienne table ; à l'insertion soit on trouve la valeur dans l'ancienne table et on conserve l'id sinon on ajoute une nouvelle ligne.

Benjamin Dauvergne a écrit :

C'est loin d'être évident, c'est exactement le même problème que #25982 qui a été fermé sans ouvrir de ticket pour continuer (on pourrait prendre celui-ci en le renommant): si on change les valeurs de filtrage on va casser toutes les visualisations actuelles qui utilisent ces valeurs.

Elles sont déjà cassées car elles pointent vers des mauvais formulaires.
Donc rajouter un slug ou figer les id, je pense qu'on pourra zapper les migrations côté bijoe.

Oui c'est peut-être cassé sur 50% des déploiements où l'ordre des formulaires a pu changer mais là ce sera cassé sur 100% des déploiements, garanti.

Premier jet avec l'ajout des méthodes qui créent des tables en y ajoutant une colonne ref et ensuite rajouter les nouvelles données.
Puis usage de ces méthodes pour stocker les categories et les formulaires. Pour les formulaires la déclaration des noms des ceux-ci et enregistrement de leurs données se font séparemment.

Serghei Mihai a écrit :

Deuxième version avec ajout implicite de la clé primaire et de la référence. Cela facilitera la transition des relations basées sur les id à celles des références.

• tu pourrais ajouter deux méthode do_category_table() et do_formdef_table()
• Comme update_sequence_table_number() est factorisé, l'utiliser en fin d'insertion des valeurs dans les tables (ça n'a pas de conséquence particulière de ne pas le faire pour l'instant mais je trouve ça bien de conserver les invariants que n'importe qui espère d'une base postgres normale)
• ref devrait être unique (simplement rajouter unique après le type varchar)
• il me me semble qu'avec le changement de schéma des tables category et formdef la reprise bête et méchante à base '*' ne va pas marcher comme on veut, on aura jamais de valeur ref pour les valeurs existantes et donc on va avoir des doublons lors de la détection to_insert (ref étant nullable l'insert des vieilles valeurs dans la nouvelle table va marcher, mais ref sera nul pour toutes les lignes).
  

          if self.prev_table_exists(name):
              # Insert data from previous table
              self.ex(
                  'INSERT INTO {schema_temp}.{name} SELECT * FROM {schema}.{name}',
                  ctx={'name': quote(name)}
              )
              self.update_table_sequence_number(name)
  

  
  Il va falloir prévoir de:
  1. détecter que la table existante n'a pas de ref,
  2. faire des update spécifique dans ce cas en fonction du name
• On est en postgresql 9.6 on peut utiliser UPSERT pour se simplifier la vie (on aura automatiquement le suivi du name si jamais il change)
  

  INSERT INTO category (ref, name) VALUES (...)
  ON CONFLICT (ref) DO UPDATE SET name = EXCLUDED.name;
  

  
  et laissant la base maintenir l'id toute seule (plus besoin de faire enumerate)

Je zappe exprès l'état actuel car du côté bijoe seuls les id comptent.
Il était question de passer sur toutes les instances de bijoe pour mettre à jour les id en fonction des libellés séléctionnés, mais ils sont déjà érronnées.

Donc autant partir de zéro.

Ok mais alors vire complètement la récupération des données du schéma précédent et gère les items aussi; ça va effectivement péter 100% des visus (dans l'idée que ça sert à rien de péter à moitié maintenant pour péter à 100% plus tard).

Serghei Mihai a écrit :

Ok, récupération du schéma précedent viré.

Ok mais il manque les modifications au schéma (JSON) pour bijoe pour utiliser le slug ou le label comme valeur dans les filtres (dans dimensions[*].value), actuellement c'est category.id et formdef.id.

Pas compris pour la gestion des items. Lequels?

Oublions on fera un autre ticket.