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

Support for changing database in model configuration #126

Merged
merged 12 commits into from
May 25, 2021
Merged

Support for changing database in model configuration #126

merged 12 commits into from
May 25, 2021

Conversation

semcha
Copy link
Contributor

@semcha semcha commented Mar 31, 2021

Fixes #110.

@semcha
Copy link
Contributor Author

semcha commented Mar 31, 2021

@swanderz Why circleci run only unit test?

@dataders
Copy link
Collaborator

dataders commented Apr 1, 2021

@swanderz Why circleci run only unit test?

not sure it was saying "unauthorized". I was able to manually re-run the checks and they are passing now. but wanna take a look at this list and see if some might apply to you? You have a CircleCI account right?
https://support.circleci.com/hc/en-us/articles/360050273651-Builds-Unauthorized-due-to-contexts

@dataders dataders requested a review from mikaelene April 1, 2021 03:30
Copy link
Collaborator

@dataders dataders left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The CircleCI tests are passing for Azure SQL, but I'm think I'm going to test this out over the next few days.

dbt/include/sqlserver/macros/adapters.sql Outdated Show resolved Hide resolved
dbt/include/sqlserver/macros/adapters.sql Outdated Show resolved Hide resolved
Comment on lines 113 to 124
{% macro sqlserver__create_view_exec(relation, sql) -%}
{%- set temp_view_sql = sql.replace("'", "''") -%}
execute('create view {{ relation.include(database=False) }} as
{{ temp_view_sql }}
');
{% endmacro %}


{% macro sqlserver__create_view_as(relation, sql) -%}
create view {{ relation.schema }}.{{ relation.identifier }} as
{{ sql }}
use [{{ relation.database }}];
{{ sqlserver__create_view_exec(relation, sql) }}
{% endmacro %}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@semcha was the reason for this to make the macro run in a single transaction?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is your suggestion? :)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think my suggestion would be:

{% macro sqlserver__create_view_as(relation, sql) -%}
  use [{{ relation.database }}];
  create view {{ relation.include(database=false) }} as
    {{ sql }}
{% endmacro %}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@swanderz That way you get an error 'CREATE VIEW' must be the first statement in a query batch.

Copy link
Collaborator

@dataders dataders left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@semcha have you tried running a dbt project after installing the adapter from this branch? I'd be interested if it works as we hope.

@semcha
Copy link
Contributor Author

semcha commented Apr 5, 2021

@swanderz Yep, it's currently running on my production server

@dataders
Copy link
Collaborator

dataders commented Apr 5, 2021

ok cool. so you're enabled in the short-term then. It's on my plate to see if this plays nicely with dbt-synapse. I hope to have time this week to do so. Thanks for all your work on this so far @semcha! this is the number one requested feature

Copy link
Collaborator

@mikaelene mikaelene left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, This is all ok with me! @swanderz , do you have questions if this will work with Synapse to handle before merging?

@dataders
Copy link
Collaborator

Hi, This is all ok with me! @swanderz , do you have questions if this will work with Synapse to handle before merging?

yeah this is the last piece. I should have time to check in the next few days

@panasenco
Copy link

Thank you @semcha for this PR! I totally dropped the ball on this. I just experienced a No item can be found error that was fixed by switching to your branch, so your code is more reliable than mine. Great job, hope this gets merged soon!

@panasenco
Copy link

Hi, could someone go ahead and merge this? :)

@dataders
Copy link
Collaborator

dataders commented May 4, 2021

Hey @panasenco we definitely want to merge this, but I need to test these changes with dbt-synapse which I haven't had the time to do yet. I promise to do it this week sometime.

In the meantime, you can use this branch by installing this branch from GitHub or by cloning it locally and calling pip install -e . from the repo directory after checking out this branch.

@panasenco
Copy link

Yeah, I've been doing that, so no worries. :)

@dataders dataders requested a review from mikaelene May 8, 2021 20:30
Copy link
Collaborator

@dataders dataders left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@semcha, I inititally made microsoft/dbt-synapse#49 to prove to you that this PR, won't work only to realize that only a few changes would be necessary!

@mikaelene, this PR is ready to merge, provided you're okay with releasing a v0.19.1 instead of a v0.19.0.3!

dbt/include/sqlserver/macros/adapters.sql Outdated Show resolved Hide resolved
dbt/include/sqlserver/macros/adapters.sql Outdated Show resolved Hide resolved
dbt/include/sqlserver/macros/adapters.sql Outdated Show resolved Hide resolved
@visch
Copy link

visch commented May 25, 2021

Just ran into this myself, wasted a bunch of time on it. I should have checked this PR first. Thanks for the work here!

@dataders
Copy link
Collaborator

I'll merge later today. @mikaelene will have to publish a release to PyPi though.

@visch
Copy link

visch commented May 25, 2021

Smoke test.
My problem may be attached to #135 , but after updating the macros in my project manually I noticed some curious behavior.

One of my source tables isn't populated (I'd expect my staging model to fail) , the model looks like this

with source as (

        select
        *
        from {{ source('raw', 'nodata') }}    

), final AS (
	select 
	*
	from source
)
select * from final

DBT reports this as running successfully after updating the macro. Even though my raw data doesn't exist. Looking at the dbt log and running the generated sql manually the command fails with something like this

Msg 208, Level 16, State 1, Procedure sourcemodel__dbt_tmp_temp_view, Line 6 [Batch Start Line 0]
Invalid object name 'raw.nodata'.
Msg 208, Level 16, State 1, Line 33
Invalid object name 'sourcemodel__dbt_tmp_temp_view'.

Completion time: 2021-05-25T12:20:51.9277966-06:00

@visch
Copy link

visch commented May 25, 2021

Smoke test.
My problem may be attached to #135 , but after updating the macros in my project manually I noticed some curious behavior.

One of my source tables isn't populated (I'd expect my staging model to fail) , the model looks like this

with source as (

        select
        *
        from {{ source('raw', 'nodata') }}    

), final AS (
	select 
	*
	from source
)
select * from final

DBT reports this as running successfully after updating the macro. Even though my raw data doesn't exist. Looking at the dbt log and running the generated sql manually the command fails with something like this

Msg 208, Level 16, State 1, Procedure sourcemodel__dbt_tmp_temp_view, Line 6 [Batch Start Line 0]
Invalid object name 'raw.nodata'.
Msg 208, Level 16, State 1, Line 33
Invalid object name 'sourcemodel__dbt_tmp_temp_view'.

Completion time: 2021-05-25T12:20:51.9277966-06:00

Just to be clear, this pull request makes the code better than it was before so I'd say go ahead! Everything works on my end, it's just an error caused by EXEC

@dataders dataders merged commit 679b351 into dbt-msft:master May 25, 2021
alon-r pushed a commit to alon-r/dbt-sqlserver that referenced this pull request May 26, 2021
* Support for changing database in model configuration

* Bumbed version

* Update dbt/include/sqlserver/macros/adapters.sql

* Removed unnecessary check

* drop redundancy

* 3-part versions from now on

* capitals as style guide

* document

* typo

* style: capitalized function words

Co-authored-by: Anders <swanson.anders@gmail.com>
@SportsTribution
Copy link

I'm running into problems that are similar to visch's.
Arbitrary syntax errors in models, like writing SLECT instead of SELECT, go unnotized. dbt does not report an error at all — but no model is created. This problem does not exist in dbt-sqlserver=0.19.0.1 and must have been introduced later.
I'm writing this here, because I think the problem might be related to aforementioned code changes introducing multiple sql commands without a GO in between.
flyway/flyway#718

It seems that if you execute multiple sql commands in the same jdbc statement (which happens if you don't separate each sql command with GO), and an error occurs in some DML command (for example INSERT) that is not the first one in the batch, then the MS jdbc driver does not throw any exception if you don't call getMoreResults() on the jdbc statement, until the result of the failing command is retrieved.

To be clear, I think it's Microsoft's fault, not yours! ;)

All the best
Hannes

@visch
Copy link

visch commented Jun 8, 2021

I'm running into problems that are similar to visch's.
Arbitrary syntax errors in models, like writing SLECT instead of SELECT, go unnotized. dbt does not report an error at all — but no model is created. This problem does not exist in dbt-sqlserver=0.19.0.1 and must have been introduced later.
I'm writing this here, because I think the problem might be related to aforementioned code changes introducing multiple sql commands without a GO in between.
flyway/flyway#718

It seems that if you execute multiple sql commands in the same jdbc statement (which happens if you don't separate each sql command with GO), and an error occurs in some DML command (for example INSERT) that is not the first one in the batch, then the MS jdbc driver does not throw any exception if you don't call getMoreResults() on the jdbc statement, until the result of the failing command is retrieved.

To be clear, I think it's Microsoft's fault, not yours! ;)

All the best
Hannes

Yeah it's a problem. If you could put a test case together for them on #135 I think it would help get to the bottom of it. I haven't had the time to prove myself :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Changing the database via {{ config(database='OTHER_DB') }} doesn't work
6 participants