Closed binhnefits closed 2 years ago
Hi @binhnefits, thanks for the report!
I tried the query in my local, but I couldn't reproduce it.
Could you share more details about your environment?
Thanks.
Hi @ueshin, thank you for looking into this issue.
I'm using dbt-databricks 1.0.2
Here is a screenshot of the SQL endpoint I'm using
Here is manifest.json configuration
"model.lakehouse.test": {
"raw_sql": "{{ config(\n materialized = 'incremental',\n incremental_strategy = 'merge',\n unique_key = 'id',\n) }}\n\nwith test as (\n select 1 as id\n)\nselect *\nfrom test\nqualify row_number() over (order BY id) = 1",
"compiled": true,
"resource_type": "model",
"depends_on": {
"macros": [
"macro.dbt_spark.dbt_spark_validate_get_file_format",
"macro.dbt_spark.dbt_spark_validate_get_incremental_strategy",
"macro.dbt.should_full_refresh",
"macro.dbt.incremental_validate_on_schema_change",
"macro.dbt.load_relation",
"macro.dbt.make_temp_relation",
"macro.dbt.run_hooks",
"macro.dbt.create_table_as",
"macro.dbt.run_query",
"macro.dbt.process_schema_changes",
"macro.dbt_databricks.dbt_databricks_get_incremental_sql",
"macro.dbt.statement"
],
"nodes": []
},
"config": {
"enabled": true,
"alias": null,
"schema": "silver_limeade_platform",
"database": null,
"tags": ["silver", "limeade_platform"],
"meta": {},
"materialized": "incremental",
"persist_docs": { "relation": true, "columns": true },
"quoting": {},
"column_types": {},
"full_refresh": null,
"on_schema_change": "ignore",
"file_format": "delta",
"location_root": "/mnt/datalake/silver/limeade_platform",
"incremental_strategy": "merge",
"unique_key": "id",
"post-hook": [
{ "sql": "VACUUM {{ this }}", "transaction": true, "index": null }
],
"pre-hook": []
},
"database": null,
"schema": "silver_limeade_platform",
"fqn": ["lakehouse", "silver", "limeade_platform", "test"],
"unique_id": "model.lakehouse.test",
"package_name": "lakehouse",
"root_path": "/home/binhpham/work/BI/lakehouse-dbt",
"path": "silver/limeade_platform/test.sql",
"original_file_path": "models/silver/limeade_platform/test.sql",
"name": "test",
"alias": "test",
"checksum": {
"name": "sha256",
"checksum": "065d1ecb756a3c4b3fda53e0a514482de13e62610d0bc489c4b843712845fdc0"
},
"tags": ["silver", "limeade_platform"],
"refs": [],
"sources": [],
"description": "",
"columns": {},
"meta": {},
"docs": { "show": true },
"patch_path": null,
"compiled_path": "target/compiled/lakehouse/models/silver/limeade_platform/test.sql",
"build_path": "target/run/lakehouse/models/silver/limeade_platform/test.sql",
"deferred": false,
"unrendered_config": {
"persist_docs": { "relation": true, "columns": true },
"file_format": "delta",
"post-hook": "VACUUM {{ this }}",
"tags": ["limeade_platform"],
"location_root": "/mnt/datalake/silver/limeade_platform",
"schema": "silver_limeade_platform",
"materialized": "incremental",
"incremental_strategy": "merge",
"unique_key": "id"
},
"created_at": 1650476991.1954176,
"compiled_sql": "\n\nwith test as (\n select 1 as id\n)\nselect *\nfrom test\nqualify row_number() over (order BY id) = 1",
"extra_ctes_injected": true,
"extra_ctes": [],
"relation_name": "silver_limeade_platform.test"
}
Also its worth mentioning that this works on clusters
but not sql endpoints
in my databricks environment.
I've been noticing this issue as well. I had seen that it results in the temp view being created but then on the next step it isn't found to select from. We noticed it was happening for some models but not others, but hadn't identified that the qualify statement seems to be the culprit. The models that fail are using it while the ones that work are not. I also observed the failed models will run on a cluster but not a SQL endpoint. Can't get any logs right now but if you need some additional input I can get them.
Hi @binhnefits, does it work if you remove the qualify
clause?
Also its worth mentioning that this works on
clusters
but notsql endpoints
in my databricks environment.
It would be helpful if you can click the name of the SQL endpoint you created and provide a screenshot of the SQL endpoint's configuration (the "Overview" tab).
@allisonwang-db
Yes this works without qualify
, and using row_number
with cte
.
Here is SQL endpoint overview
@binhnefits Thanks for providing the info. This is a known issue with SQL endpoints and the team is actively working on fixing it (likely by the end of the month). Will give an update once the fix is rolled out to production.
Hi @allisonwang-db I was wondering if you had any updates. I noticed Datbricks released runtime 10.5
so wondering if that had the fix in it. Thanks!
@binhnefits the issue should be fixed! Please try it again and let me know if it is still not working.
hi @binhnefits any luck testing this out again? Does it work now?
Hi @allisonwang-db @superdupershant I have confirmed that it is working now. Thank you!
Describe the bug
When using
QUALIFY
in an incremental model, the view dbt creates does not exist. This prevents dbt from doing the merge statement.Steps To Reproduce
test.sql
log results:
Expected behavior
Expect view to be created and queryable to execute merge statement.
Screenshots and log output
If applicable, add screenshots or log output to help explain your problem.
System information
The output of
dbt --version
:1.04
The operating system you're using:WSL
The output ofpython --version
:Python 3.9.11
Additional context
Add any other context about the problem here.