ASGARD

En principe, il n’existe que deux situations dans lesquelles ASGARD peut interférer négativement avec les actions d’un utilisateur :

• lorsqu’il a des raisons légitimes pour vouloir qu’un objet ait (et conserve) un propriétaire différent de celui du schéma qui le contient. Ce cas de figure est très hypothétique, d’autant qu’une bonne pratique dans ces circonstances serait de créer un nouveau schéma avec comme producteur^[1] le rôle en question ;

• lorsqu’il a des raisons légitimes pour vouloir qu’un rôle de connexion^[2] non super-utilisateur^[3] soit propriétaire d’un schéma. Ce second cas de figure est souvent lié à des problématiques d’import de données, qui peuvent généralement être résolues sans enfreindre la règle de non attribution de la propriété des schémas aux rôles de connexion. Cf. Import de schémas sur ce point.

S’il s’avère absolument nécessaire de passer outre les règles d’ASGARD, il est possible :

• de déréférencer a posteriori un schéma de la table de gestion avec la fonction asgard_sortie_gestion_schema (dans z_asgard_admin, utilisable uniquement par les membres de g_admin[4]). Ce schéma et son contenu ne seront alors plus pris en compte par aucun des mécanismes automatisés d’ASGARD, ce qui permettra notamment de désynchroniser les propriétaires des objets ;

• de désactiver temporairement le déclencheur sur événement asgard_on_create_schema, afin que les schémas créés dans l’intervalle ne soient pas enregistrés dans la table de gestion^[5]. Seul le super-utilisateur peut procéder à cette désactivation et à la réactivation ultérieure.

Pour désactiver le déclencheur sur événement :

ALTER EVENT TRIGGER asgard_on_create_schema DISABLE ;

ALTER EVENT TRIGGER asgard_on_create_schema DISABLE ;

Pour le réactiver :

ALTER EVENT TRIGGER asgard_on_create_schema ENABLE ;

ALTER EVENT TRIGGER asgard_on_create_schema ENABLE ;