<@U088WCP3B4P> After running `dbt run --select ele...
# ask-elementary-ai
b
@kapa.ai After running
dbt run --select elementary
I checked the table
dbt_tests
. For some reason a few of my tests show up in this table with the wrong value in the
schema
column. I expect it to be
"analytics_mart"
but instead i see
"dbt_test__audit"
. Why is this happening?
k
A message from kapa.ai
This usually happens when your project overrides dbt’s generate_schema_name macro. dbt tests use a built‑in custom schema name dbt_test__audit; if your custom macro logic is picked up when Elementary parses test metadata, the schema value saved for those tests becomes dbt_test__audit instead of the tested table’s schema (analytics_mart). Elementary identified this issue and fixed it so schema_name reflects the tested table’s schema even when generate_schema_name is overridden. [[dbt_test__audit issue](https://slack.com/archives/C02CTC89LAX/p1673321077310119); [Follow‑up and fix PR](https://slack.com/archives/C02CTC89LAX/p1673321077310119)]
b
@kapa.ai It's still not fixed in my context. I have a base project where my models' properties (with the tests) are defined, and the sql files for the same models are located in a different project (which depends on the base). I think that's somehow preventing elementary from understanding which schema a test is associated with.
k
A message from kapa.ai
Thanks for the added context. Based on our knowledge sources, Elementary’s schema mislabeling (showing dbt_test__audit instead of the tested table’s schema) occurs when dbt’s generate_schema_name is overridden, because tests use a built‑in custom schema name dbt_test__audit. Elementary addressed this with a fix so schema_name reflects the tested object even when the macro is overridden. [[dbt_test__audit issue](https://slack.com/archives/C02CTC89LAX/p1673321077310119)] However, the sources don’t mention or confirm behavior with split projects (tests defined in a base project and models in a dependent project). I’m sorry, but there’s no information about this multi‑project properties/models split scenario and how it might affect schema resolution in Elementary. [[dbt_test__audit issue](https://slack.com/archives/C02CTC89LAX/p1673321077310119)] Given known limitations, Elementary does not support multiple dbt projects writing into the same Elementary schema, and cross‑project metadata can be incomplete or overwritten, which may relate to your setup. The recommended approach is a separate Elementary schema per project. [[Multi‑project not supported](https://slack.com/archives/C02CTC89LAX/p1691513076109829); [Per‑project schema](https://slack.com/archives/C02CTC89LAX/p1698049255491119)] If you can, try: - Ensuring your generate_schema_name excludes Elementary from custom logic so Elementary models/tests land in the intended schema. [[Exclude Elementary](https://slack.com/archives/C02CTC89LAX/p1712851926036669)] - Running dbt run -s elementary in each project separately, pointing to distinct Elementary schemas, and checking whether schema_name is correct in dbt_tests in each schema. [[Per‑project run](https://slack.com/archives/C02CTC89LAX/p1691513076109829)] If you share a snippet of your generate_schema_name and how the two projects’ profiles/schemas are set, we can suggest an exact macro tweak.