Produits Entr'ouvert » OLAP / Business Intelligence pour Publik

On peut laisser les noms de cube tranquille, peu de chance d'avoir une collision sur le préfixe, le souci est principalement sur les objets en base (index, table pour les champs à choix multiple) mais ceux-ci ne sont pas référencés dans les objets de configuration.

Donc oui augmenter le hash à 8 caractère pour tout le monde mais utiliser l'ancien hash pour la clé name ici :

 887         cube.update({
 888             'name': self.cube_name,
 889             'label': self.formdef.schema.name,
 890             'fact_table': self.table_name,
 891             'key': 'id',
 892         })

et

    @property
    def cube_name(self):
        # hash_length is 6 for retro-compatibility with existing visualizations which references cube by their name
        return self.hash_table_name('formdata_%s' % self.formdef.slug.replace('-', '_'), hash_length=6)

En fait on pourrait même abandonner le système des hashs pour les noms des objets, j'ai suivi la façon de faire de Django mais le contexte est en fait différent, Django a besoin d'une génération déterministe quand on rejoue les migrations, pas nous. On pourrait donc s'en sortir avec une fonction qui mémoise les noms raccourcis pendant la génération et un compteur.

    table_counter = 0
    table_map = None

    def adapt_table_name_to_pg(self, table_name):
        '''Truncate long table name, adding suffix identifier to prevent collisions.
        '''
        table_name = table_name.format(**self.default_ctx)
        if self.table_map is None:
            self.table_map = {}
        if table_name in self.table_map:
            return self.table_map[table_name]
        if len(table_name) >= 58:
            table_name = self.table_map[table_name] = '%s_%04d' % (table_name[:58], self.table_counter)
            self.table_counter += 1
        return table_name

Et en finissant d'écrire je me dis que ce n'est pas forcément une bonne idée si on vise à moyen terme un chargement incrémental, on reviendra dans la situation de Django où on doit pouvoir retrouver les mêmes noms d'un chargement sur l'autre; idéalement w.c.s. nous servirait des UUIDs sur ses objets de configuration, ça nous aiderait même en cas de changement de slug.

(...) le souci est principalement sur les objets en base (index, table pour les champs à choix multiple) mais ceux-ci ne sont pas référencés dans les objets de configuration.

Mais il y a aussi #30752 qui assure des identifiants stables pour les listes de choix, qui a besoin de retrouver la table créée à l'exécution précédente; il me semble.

_~~

J'ai poussé une branche wip/33009-hash-length en suivant ton commentaire précédent, mais pas sûr.

Le hash_table_name() et le self.cube_name créé, ils ne sont pas dans la même classe, patch légèrement adapté.

Frédéric Péters a écrit :

Mais il y a aussi #30752 qui assure des identifiants stables pour les listes de choix, qui a besoin de retrouver la table créée à l'exécution précédente; il me semble.

_~~

J'ai poussé une branche wip/33009-hash-length en suivant ton commentaire précédent, mais pas sûr.

Tu as raison pour #30752, parrons au plus pressé, laisse le hash_length à 6 par défaut, laisse cube_name comme il est avec la répétition du 6 et on passe à 8 seulement pour les index, on pourra fignoler pour les tables de fait et les tables filles plus tard, pour l'instant on a eu une collision qu'entre un index et une table.

Je viens de pousser 0001-misc-increase-json-index-table-name-hash-size-33009.patch dans la branche wip.

Je me rends compte (recevant à nouveau la même trace) que j'ai zappé le suivi ici; le patch minimaliste proposé dans la branche, ok ?