Quand vous dites “doublon” vous voulez dire des indexes portant sur les mêmes colonnes mais avec un nom différent ? Je pose la question car Simplicité créé 3 types d’indexes:
des primary keys qui portent sur le row ID (colonne row_id) => suffixe en _pkey
des unique keys qui portent sur la combinaison des colonnes des attributs paramétrés comme “clés fonctionnelle” => suffixe en _uk
des indexes simples sur les colonnes de attributs de type “référence” (i.e. les foreign keys) => suffixe en _fk
des indexes simples sur les colonnes des attributs obligatoires de type chaine de caractère (donc colonnes varchar) => suffixe en _idx
Il peut donc potentiellement y avoir des doublons entre les unique keys et les indexes simples (ex: quand un objet n’a qu’un seul attribut identifiant et que celui-ci est un attribut de type chaine de caractère obligatoire).
En outre, je vois effectivement que les nommages d’index des objets de paramétrage du script de création initiale (ceux en _fk<n>) ne suivent pas la même logique de nommage que les indexes générés ultérieurement au niveau applicatif.
Du coup sur chaque objet de paramétrage sur lequel à un moment ou à un autre il y a eu un save (ex: manuel ou via une mise à jour système) ce qui induit une régénération des indexes, cela aboutit donc à des doublons d’index.
Nous allons regarder pour améliorer cela en alignant (si possible) le nommage au niveau du script initial et par un traitement ad hoc au moment du save applicatif.
PS: En attendant vous pouvez supprimer manuellement les indexes en doublon de même type (= les indexes en _fk<n> pour lesquels il y a un index identique en _fk)
Les noms d’indexes “courts” sont historiques et étaient surtout dédiés à Oracle pre-V12 qui limitait la taille des noms à 30 caractères. Donc à laisser de préférence. Oracle 12+ autorise les indexes de 128 caractères.
Il faudrait plutôt voir si on peut tester l’existence d’un index sur des colonnes avant de le recréer.
Sinon on va devoir effectivement retirer les anciens indexes en doublon avec les nouveaux noms, mais Oracle va poser problème (comme toujours).
Oui c’est ce que je voulais dire par “un traitement ad hoc au moment du save applicatif” = retrouver un éventuel index déjà existant (et, au passage, supprimer d’éventuels doublons)
Il n’y a pas d’API standardisée JDBC pour tester si un index existe sur des colonnes ordonnées. Il faudrait le développer pour chaque base de données et ce n’est pas forcement le métier de Simplicité.
Il va donc plutôt falloir :
soit recréer les indexes des tables du socle pour les rendre compatible avec le runtime qui les recrées avec un nom différent => alter global de la base assez lourd
soit ne pas générer d’index si on est sur une table socle car déjà livré avec d’autres noms courts => il faut juste prévoir de droper les autres générés par erreur avant correction.
Ok, ce changement sera livré en 5.2 actuellement en beta.
Pour supprimer les indexes en doublons (de noms différents mais sur les mêmes colonnes), il faudra relancer la tache de génération des indexes sur les objets sur lesquels vous l’aviez fait.
Du coup j’ai un doute sur ceux que vous avez supprimés ?
Attention, il faut bien conserver les indexes suffixés par un numéro.
Par exemple garder m_agenda_fk9, et supprimer m_agenda_agd_label4_id_fk généré en trop. @Userenault