How to ref() a table I want to keep static / skip / exclude / not run

[ptrn]

Let’s say I have a model that ref()s models of deprecated tables which will not be modified.

I have other things that depend on this model, and I’d therefore like to be able to ref() this model in those models for the dbt docs.

I also want to be able to version control the SQL.

However, I don’t ever want this model to run, because it’ll always return the same results and is therefore wasteful.

I’ve looked at analyses, seeds, and snapshots, but it seems like none fit. I’ve looked at the enabled config, but that prevents anything from referencing the model.

I know I can simply use exclude in a dbt run command, but that requires us to always remember to exclude this one model, and we’re running dbt from within Fivetran, so passing custom CLI flags isn’t even an option for us.

I’ve also looked at custom selectors, where we could default to excluding this model. However, unless I’m misunderstanding, those don’t seem very useful, given:

If I run a command that defines its own selection criteria (via --select, --exclude, or --selector), dbt will ignore the default selector and use the flag criteria instead. It will not try to combine the two.

exclude gives me exactly what I want in terms of functionality - I just need a way to apply it permanently to that model.

If this just isn’t possible, any suggestions that’ll accomplish my below objectives would be most appreciated!:

1. Keep it in the repo for documentation (using ref()s)
2. Version control the SQL

Thank you!

[wefo]

Hi @ptrn

Have you considered referring to this table as a source table?

Could you leave the disabled model, add the table to your source list, and refer to it as source(table_name)?

[a_slack_user]

I was also going to suggest creating a source, but the version control requirement makes it fiddly (you could have a disabled node as well as a source, but it’s a bit weird). Perhaps if you wanted to create it as a source, you could move the code to an analysis file?

Alternatively, you could configure it as an incremental model, and put where 1 = 0 inside of your is_incremental() block which would mean it would never change anything.

_{Note: @joellabes (dbt Labs) originally posted this reply in Slack. It might not have transferred perfectly.}

[ptrn]

Thanks for the suggestions!

Have you considered referring to this table as a source table?
Could you leave the disabled model, add the table to your source list, and refer to it as source(table_name)?

I was considering doing this, but then I don’t think I’d have any data lineage for what’s upstream from the table, since it’d be a “source”. Unless I’m misunderstanding that?

Alternatively, you could configure it as an incremental model, and put where 1 = 0 inside of your is_incremental() block which would mean it would never change anything.

Hmm yeah. This could do it! Probably the best approach now.

I appreciate the help!

[wefo]

The proposed solution has one caveat which you should consider, if you place the condition in is_incremental block, it would not work on full-refresh.

Maybe you should also add full-refresh: false in config block

full_refresh | dbt Developer Hub

[ptrn]

Hey thanks. That’s a great callout; I wouldn’t have thought of that!