Merge branch 'main' into bug/223-relationship-test-with-limit

# Conflicts:
#	CHANGELOG.md

CHANGELOG.md

@@ -1,5 +1,7 @@
-### Release [1.7.2], 2024-XX-XX
-#### Bug Fixes
+### Release [1.7.2], 2024-02-09
+#### Bug Fix
+- Fixed an issue where Materialize Views would break with a custom schema.  Thanks to [Rory Sawyer](https://github.com/SoryRawyer)
+for the PR!
 - A few tests with LIMIT clause were broken due to parsing error when having settings in the query ([issue](https://github.com/ClickHouse/dbt-clickhouse/issues/223)). We added a dedicated limit placer, that takes into account the settings section (using a comment flag `-- settings_section` within the query).
 
 ### Release [1.7.1], 2023-12-13

README.md

@@ -156,8 +156,7 @@ operations, because they don't require rewriting ClickHouse data parts.  The inc
 incremental materializations that perform significantly better than the "legacy" strategy.  However, there are important caveats to using this strategy:
 - Lightweight deletes must be enabled on your ClickHouse server using the setting `allow_experimental_lightweight_delete=1` or you 
 must set `use_lw_deletes=true` in your profile (which will enable that setting for your dbt sessions)
-- As suggested by the setting name, lightweight delete functionality is still experimental and there are still known issues that must be resolved before the feature is considered production ready,
-so usage should be limited to datasets that are easily recreated
+- Lightweight deletes are now production ready, but there may be performance and other problems on ClickHouse versions earlier than 23.3.
 - This strategy operates directly on the affected table/relation (with creating any intermediate or temporary tables), so if there is an issue during the operation, the
 data in the incremental model is likely to be in an invalid state
 - When using lightweight deletes, dbt-clickhouse enabled the setting `allow_nondeterministic_mutations`.  In some very rare cases using non-deterministic incremental_predicates

dbt/adapters/clickhouse/__version__.py

@@ -1 +1 @@
-version = '1.7.1'
+version = '1.7.2'

dbt/include/clickhouse/macros/materializations/materialized_view.sql

@@ -41,7 +41,7 @@
       {{ clickhouse__get_create_materialized_view_as_sql(target_relation, sql) }}
     {%- endcall %}
   {% elif existing_relation.can_exchange %}
-    {{ log('Replacing existing materialized view' + target_relation.name) }}
+    {{ log('Replacing existing materialized view ' + target_relation.name) }}
     {% call statement('drop existing materialized view') %}
       drop view if exists {{ mv_relation }} {{ cluster_clause }}
     {% endcall %}
@@ -50,10 +50,10 @@
     {%- endcall %}
     {% do exchange_tables_atomic(backup_relation, existing_relation) %}
     {% call statement('create new materialized view') %}
-      {{ clickhouse__create_mv_sql(mv_relation, existing_relation.name, cluster_clause, sql) }}
+      {{ clickhouse__create_mv_sql(mv_relation, existing_relation, cluster_clause, sql) }}
     {% endcall %}
   {% else %}
-    {{ log('Replacing existing materialized view' + target_relation.name) }}
+    {{ log('Replacing existing materialized view ' + target_relation.name) }}
     {{ clickhouse__replace_mv(target_relation, existing_relation, intermediate_relation, backup_relation, sql) }}
   {% endif %}
 

tests/integration/adapter/materialized_view/test_materialized_view.py

@@ -25,6 +25,7 @@
        materialized='materialized_view',
        engine='MergeTree()',
        order_by='(id)',
+       schema='custom_schema',
 ) }}
 
 {% if var('run_type', '') == '' %}
@@ -92,6 +93,7 @@ def test_create(self, project):
         2. create a model as a materialized view, selecting from the table created in (1)
         3. insert data into the base table and make sure it's there in the target table created in (2)
         """
+        schema = quote_identifier(project.test_schema + "_custom_schema")
         results = run_dbt(["seed"])
         assert len(results) == 1
         columns = project.run_sql("DESCRIBE TABLE people", fetch="all")
@@ -101,10 +103,10 @@ def test_create(self, project):
         results = run_dbt()
         assert len(results) == 1
 
-        columns = project.run_sql("DESCRIBE TABLE hackers", fetch="all")
+        columns = project.run_sql(f"DESCRIBE TABLE {schema}.hackers", fetch="all")
         assert columns[0][1] == "Int32"
 
-        columns = project.run_sql("DESCRIBE hackers_mv", fetch="all")
+        columns = project.run_sql(f"DESCRIBE {schema}.hackers_mv", fetch="all")
         assert columns[0][1] == "Int32"
 
         check_relation_types(
@@ -123,7 +125,7 @@ def test_create(self, project):
         """
         )
 
-        result = project.run_sql("select count(*) from hackers", fetch="all")
+        result = project.run_sql(f"select count(*) from {schema}.hackers", fetch="all")
         assert result[0][0] == 4
 
 
@@ -145,6 +147,7 @@ def models(self):
         }
 
     def test_update(self, project):
+        schema = quote_identifier(project.test_schema + "_custom_schema")
         # create our initial materialized view
         run_dbt(["seed"])
         run_dbt()
@@ -162,6 +165,6 @@ def test_update(self, project):
 
         # assert that we now have both of Dade's aliases in our hackers table
         result = project.run_sql(
-            "select distinct hacker_alias from hackers where name = 'Dade'", fetch="all"
+            f"select distinct hacker_alias from {schema}.hackers where name = 'Dade'", fetch="all"
         )
         assert len(result) == 2