Based on the available knowledge sources, there is no explicit information confirming incompatibility between Elementary (any version, including 0.20.1) and dbt-databricks 1.11.0. However, the error you are seeing:

Compilation Error in operation elementary-on-run-start-0 (./dbt_project.yml)   'Row' object has no attribute 'lower'

is similar to previously reported issues when disabling Elementary models or misconfiguring the enabled flag in dbt_project.yml. In several cases, using Jinja or vars in the enabled flag, or disabling models in certain ways, led to similar

'NoneType' object has no attribute 'lower'

or related errors. For example, using a Jinja expression in the enabled flag or disabling models via vars has been problematic in the past and is not always supported as expected by dbt or Elementary, especially across different dbt versions and adapters. Removing the use of vars or complex Jinja in the enabled flag and instead excluding Elementary models via CLI commands has resolved similar issues for other users [see example](https://slack.com/archives/C02CTC89LAX/p1697671984193989). Additionally, there have been reports that certain errors (such as attribute errors on 'lower') can occur when Elementary is applied to ephemeral models or when the configuration in dbt_project.yml is not at the correct level or uses unsupported syntax [see example](https://slack.com/archives/C02CTC89LAX/p1690979306223489). There is no direct mention of dbt-databricks 1.11.0 compatibility issues, but there are known issues with how Elementary interacts with Databricks, especially regarding model disabling and schema configuration. In some cases, using the enabled flag in dbt_project.yml did not work as expected, and the recommended workaround was to use CLI exclusions or to disable Elementary hooks using vars instead of the enabled flag [see example](https://slack.com/archives/C02CTC89LAX/p1684140627395549). Summary: The knowledge sources do not explicitly state that Elementary 0.20.1 is incompatible with dbt-databricks 1.11.0. However, your error is consistent with known issues around disabling Elementary models using the enabled flag or vars in dbt_project.yml, especially with Databricks. Try removing the Jinja logic from the enabled flag and instead exclude Elementary models via CLI, or use the recommended vars-based disabling approach. If the issue persists, it may be worth reaching out to Elementary support or checking for updates on compatibility with dbt-databricks 1.11.0. If you need to disable Elementary in non-prod environments, consider this approach in your dbt_project.yml:

yaml vars:   disable_run_results: "{{ target.name != 'prod' }}"   disable_tests_results: "{{ target.name != 'prod' }}"   disable_dbt_artifacts_autoupload: "{{ target.name != 'prod' }}"   disable_dbt_invocation_autoupload: "{{ target.name != 'prod' }}"

[See discussion and workaround](https://slack.com/archives/C02CTC89LAX/p1684140627395549). If you need further help, please provide more details or check for updates from the Elementary team.

Based on the knowledge sources, the most common root cause for Elementary models not being created in the correct schema—or for errors related to schema configuration—is the indentation or placement of the

elementary

block in your

dbt_project.yml

. The

elementary

configuration must be a direct child of the

models:

section, not nested under your project name or any other section. Incorrect placement can cause dbt to ignore the config or apply it incorrectly, especially with Databricks. Correct placement:

yaml models:   your_project_name:     # your other model configs    elementary:     +schema: elementary

Incorrect placement (causes issues):

yaml models:   your_project_name:     elementary:       +schema: elementary

or

yaml elementary:   +schema: elementary

This issue has been reported and resolved multiple times by ensuring the correct indentation and placement of the

elementary

block. For Databricks specifically, users have confirmed that moving the

elementary

config to be a direct child of

models:

resolves schema-related issues and errors like the one you described [

'Row' object has no attribute 'lower'

]([see example](https://slack.com/archives/C02CTC89LAX/p1668792958784389), [see example](https://slack.com/archives/C02CTC89LAX/p1680270133127419), [see example](https://slack.com/archives/C02CTC89LAX/p1684341029701899)). Action steps: 1. Ensure your

dbt_project.yml

has the

elementary

config as a direct child of

models:

. 2. Remove any nesting under your project name or other sections. 3. Re-run

dbt run --select elementary

. If you still encounter issues, double-check for any custom

generate_schema_name

macros that might interfere with schema assignment, and ensure they properly handle the

elementary

package as shown in the knowledge sources. If the error persists after these changes, the knowledge sources do not provide further troubleshooting steps specific to dbt-databricks 1.11.0, so you may need to reach out to Elementary support for more targeted help.

Yes, there are alternative ways to define the schema for Elementary models in dbt, beyond just using the

+schema

config in

dbt_project.yml

. ### 1. Using a Custom

generate_schema_name

Macro You can override dbt's default schema naming logic by implementing your own

generate_schema_name

macro. This allows you to fully control how schemas are assigned, including for the Elementary package. For example, you can set a specific schema for Elementary by checking for a config or meta field:

jinja {% macro generate_schema_name(custom_schema_name, node) -%}     {%- set default_schema = target.schema -%}     {% set config_meta = node.config.get('meta') %}     {% if config_meta and config_meta is mapping %}         {% set schema_name = config_meta.get('schema_name') %}         {% if schema_name and schema_name is string %}             {{ return(schema_name) }}         {% endif %}     {%- elif custom_schema_name is none -%}         {{ default_schema }}     {%- else -%}         {{ default_schema }}_{{ custom_schema_name | trim }}     {%- endif -%} {%- endmacro %}

Then, in your

dbt_project.yml

, you can use the

+meta

config to set the schema name:

yaml models:   elementary:     +meta:       schema_name: "elementary_data_observability"

This approach gives you more flexibility and can be combined with environment variables if needed. [See FAQ and example](https://docs.elementary-data.com/oss/general/faq) ### 2. Using Environment Variables in the Macro You can also use environment variables within your custom macro or in the

dbt_project.yml

to dynamically set the schema name based on the environment. ### 3. Setting Schema in

profiles.yml

For CLI operations (like

edr report

), the schema used is determined by the

schema

field in your

profiles.yml

under the appropriate profile and target. Adjusting this value will direct Elementary to use a different schema for its operations. [See example](https://slack.com/archives/C02CTC89LAX/p1696270989954349) --- If you need to separate the schema for Elementary test tables, you can also use the

tests_schema_name

variable:

yaml vars:   tests_schema_name: 'elementary_tests'

[See example](https://slack.com/archives/C02CTC89LAX/p1680270133127419) --- In summary: - You can define the schema via

+schema

in

dbt_project.yml

(with correct placement). - You can use a custom

generate_schema_name

macro for more advanced logic. - You can set the schema in

profiles.yml

for CLI operations. - You can use the

tests_schema_name

variable for test result tables. If you need more specific examples, let me know your use case!