Anomalie #393
ouvertNon affichage de ressources avec AsgardMenu
0%
Description
Pb soulevé par Gilles Ribeyre DTT07. Le pb qui initialement semble concerner AsgardMenu est décrit ici car la solution concerne Asgard.
extrait message initial : 'La première base que j'ai déclaré dans le menu de configuration (dv3f) remonte impeccable. Les autres ne remontent pas (dans le menu)'.
Après échanges de message Gilles Ribeyre indique avoir trouvé la solution :
extrait message : 'Je vous envois ce petit mail pour vous décrire la solution à mon problème.
En fait, l'origine était l'exécution incorrecte de la fonction : SELECT z_asgard_admin.asgard_initialisation_gestion_schema() ;
La table z_asgard_admin.gestion_schema restait vide.
Le problème initial était le fait que le propriétaire de plusieurs schémas était un rôle de connexion.
Après avoir remplacé ce rôle par 'postgres', tout est rentré dans l'ordre.'
-> Peut-être vérifier que si le propriétaire de schéma existant est un rôle de connexion, çà pose pb (ou pas) à l'initialisation de gestion_schema.
Mis à jour par Leslie Lemaire il y a plus de 3 ans
- Version cible mis à asgard--1.3
- Assigné à mis à Leslie Lemaire
Bonjour Alain,
Il y a bien un test lors de l'initialisation pour vérifier que les propriétaires des schémas ne sont pas des rôles de connexion, et c'est lui qui produit une erreur dans le cas contraire. Comme la fonction a échoué, la table de gestion reste vide. Pas d'anomalie donc dans ce que décrit Gilles Ribeyre, c'est le comportement normal d'ASGARD. Par contre, il y a sans doute un déficit d'explications, tu peux le remercier de l'avoir signalé.
Le message renvoyé par asgard_initialisation_gestion_schema est explicite (ci-dessous), mais il n'y a ni HINT ni DETAIL, je pourrais le compléter en indiquant qu'il est nécessaire de corriger manuellement le propriétaire avant exécution.
ERREUR: FIG0 > TA0 > TA3. Opération interdite (schéma test_jsnow). Le producteur/propriétaire du schéma ne doit pas être un rôle de connexion.
Je vais surtout compléter la documentation en évoquant ce cas d'erreur dans la partie VI.5 et en le détaillant dans le descriptif de la fonction asgard_initialisation_gestion_schema.
Plus largement, je me demande aussi s'il ne faudrait pas commencer par expliquer comment fonctionnent les erreurs PostgreSQL. Dire que s'il y a un message avec écrit "ERREUR"/"ERROR", alors la commande qui avait été lancée n'a eu aucun effet. Ce sera plus facile à faire avec Scenari, sans doute avec un item Définition.