-
Notifications
You must be signed in to change notification settings - Fork 30
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
Schema not automatically created in secondary warehouse #233
Comments
I think adding USE database statement should work, however, there are few catalog queries which require additional work. I will not prioritize this for V1.8.8. However, will start looking into this soon. |
I am working with a team who is also experiencing the exact same issue. |
* configuring local tests to run on user credentials. Dropping a relation correctly based on its type * Addressing #243, #221, #228, #229, #232, #235 issues * Updated test helper with ephemeral * Updated unit tests * Updated get_pyodbc_attrs_before_credentials method * include only lines that start with order by * Addressed issue #249,#240,#238,#233,#180,#168,#186,#52 * Ensure Testview Name Uniqueness with MD5 of Model Name and Invocation * Updating integration tests
Addressed this change in #251. All integration tests are passing. Test and let me know if you still this issue. Please re-open if required. |
If you attempt to materialize a model in a second warehouse by setting its
database
property (and you've already materialized at least one model in your target database), you receive the following error:It seems that the
fabric__list_schemas
macro indbt/include/fabric/macros/adapters/metadata.sql
always runs against the target database, not the database configured for the relation. I think this could be resolved by adding aUSE {{database}}
statement immediately above theselect ... from sys.schemas
statement:Reproduction steps
WH_Primary
andWH_Secondary
WH_Primary
and the schema to bedbt_mycustomschema
WH_Primary
underdbt_mycustomschema
WH_Secondary
.This is because when the adapter attempts to materialize the second model and checks for the existence of the schema, it checks in the
WH_Primary
database (in which it exists because of step 3) and skips creating it.The text was updated successfully, but these errors were encountered: