Il n'est pas rare de vouloir avoir un seul script pour déployer un changement. Le fait est qu'un tel script doit être exécuté par un utilisateur expérimenté, car il doit disposer de privilèges système au niveau ANY. Cela signifie généralement un compte DBA, de préférence un compte d'application, mais sinon SYSTEM ou SYS.
Ainsi, le script que vous voulez ressemblerait à ceci :
grant select on user_a.t23 to user_b
/
grant select on user_a.t42 to user_b
/
create view user_b.v_69 as
select t23.col1, t42.col2
from user_a.t42
join user_a.t23
on (t42.id = t23.id)
/
grant select on user_b.v_69 to user_c
/
Un scénario courant est que nous avons une suite de scripts individuels qui ont été écrits pour être exécutés par différents utilisateurs, mais que nous devons maintenant regrouper en un seul déploiement. Les scripts originaux ne contiennent pas les noms de schéma, et il existe de nombreuses bonnes raisons pour lesquelles nous ne voudrions pas les coder en dur dans les scripts.
Une façon de créer ce script principal consiste à modifier la syntaxe CURRENT_SCHEMA :
alter session set current_schema=USER_A
/
@run_grants_to_userb.sql
alter session set current_schema=USER_B
/
@create_view69.sql
@run_grants_to_userc.sql
Nous avons toujours besoin d'un utilisateur DBA pour exécuter le script maître. L'un des avantages du changement de schéma actuel est qu'il nous permet de déployer des objets tels que des liens de base de données, qui, par une bizarrerie de syntaxe, ne peuvent pas avoir le nom du schéma dans leur déclaration. Un piège est que l'utilisateur ne change pas, donc un script qui utilise la pseudo-colonne USER peut produire des résultats indésirables.
