Add a way to define the "inputs" of DBT model in the contract

[frco9]

The contract feature is nice to help model reusability across different projects. However it only concerns the columns, i.e the output of the contract.

In most IT system when you define an interface, or a contract, you usually define the expected input and the expected output.

I think there is a part missing in the current implementation of DBT contract, as we only defining the output. It would be nice to also be able to define the input.

For exemple we have some models that are using vars, to adjust a "where" condition to not have to hardcode it in the model.
However, we can't rely on the contract and versioning properly as adding, updating or removing one of the vars could lead to a breaking change in the underlying models reusing this source model.

[jtcohen6]

@frco9 Thanks for opening - I'm interested in hearing more! Could you provide a specific example?

-- models/my_model.sql
select * from {{ ref("upstream") }}
where {{ var("my_where_condition", "1=1") }}

However, we can't rely on the contract and versioning properly as adding, updating or removing one of the vars could lead to a breaking change in the underlying models reusing this source model.

Would the change to this var be a breaking change to the structure of the model (column names & types)? To the number of rows in the model's output?

you usually define the expected input and the expected output

When I read this, it made me think of thematically related work that we've started around unit testing:

• Unit Testing #8275