Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] multi schema materializations not supported without administrative privileges #61

Open
1 task done
geoHeil opened this issue Dec 22, 2022 · 0 comments
Open
1 task done
Assignees
Labels
bug Something isn't working

Comments

@geoHeil
Copy link

geoHeil commented Dec 22, 2022

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

multi schema materializations not supported without administrative privileges

Expected Behavior

DBT should be able to populate pre created schemata without administrative permissiones required to execute a CREATE table in these schematas.

A proxy connect is not a viable workaround as it is explicit and cannot implicitly be inferred - as far as I understand.

Steps To Reproduce

DBT can nicely generate schemata in other databases (postgres, snowflake, ...). However, this is tricky as my DBT account has no administrative permissions. Rather, it is confined to 3 schemata a_raw, b_staging, c_mart. However, while my user foo foo[a_raw] has proxy-connect privileges to all a,b,c schemata DBT only has a single target (i.e. foo[a_raw] ) that can be registered. This means I would need to break down the dbt run into 3 separate callls to the cli and also that the nice selector for upstream models no longer works due to insufficient permissions. How can I change the situation to allow the dbt user (foo) to read/write all a,b,c schemata? My DBA is telling me that Oracle cannot grant CREATE permissions to any other user besides the specific schema user (and administrators) but he is not going to hand me administrative privileges. What can I do to return back to a dbt native situation?

This means when changing the target user from foo[a_raw] to foo[b_staging] to foo[c_mart] (explicitly) CREATE permissions are there. Otherwise not.

Relevant log output using --debug flag enabled

No response

Environment

- OS: windows
- Python: 3.10
- dbt: 1.3.1

What Oracle database version are you using dbt with?

11 and hopefully soon 19c

Additional Context

No response

@geoHeil geoHeil added the bug Something isn't working label Dec 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants