[CT-2314] [Feature] Do we _have_ to call the boolean property contract?

[joellabes]

Is this your first time submitting a feature request?

• I have read the expectations for open source contributors
• I have searched the existing issues, and I could not find an existing issue for this feature
• I am requesting a straightforward extension of existing dbt functionality, rather than a Big Idea better suited to a discussion

Describe the feature

From reading #6748, it looks like I'm about 3 weeks late to this party. But better now than in another 3 weeks!

I haven't been following this closely, and when I saw contract: I assumed it was going to be the key of a dictionary containing all the rules of the contract, not a simple bool.

Could I make a late breaking pitch for has_contract?

Describe alternatives you've considered

• I would also accept is_contracted, but I don't think I'll get as far on that one.
• Or go back to the original naming scheme, but just change the noun (i.e. contract_enabled instead of constraints_enabled)

Who will this benefit?

People who assume we follow our style guide (yes I know this is the SQL style guide not the Python style guide, but it's going to be side-by-side with all the YAML that does follow this scheme)

Are you interested in contributing this feature?

I could if it's the only way it'll get done, but I won't be the fastest way to get it done

Anything else?

No response

[jtcohen6]

@joellabes Thanks for opening ❤️

But better now than in another 3 weeks!

Very very true!

Options:

• has_contract — my qualm with this is that it feels more descriptive than proactive, and choosing to contract a model is an intentional matter
• contract_enabled — I don't like the overlap with enabled
• enforce_contract or contract_enforced ?

In discussion with @aranke... or avoid the word contract for this (... and rename the feature???):

• strict (hearkening back to strict field validation for schema.yml #1570)
• guarantees (guaranteed_schema)?
• spec, blueprint, ...

My initial intent in using contract here was more in the sense of "API contract," than in the sense of "mutual opt-in agreement between two parties." Contracts mean different things to different people. (I've intentionally avoided the even more-vague term "data contracts.")

[joellabes]

I like enforce_contract, I like enforce_spec even more!

[jtcohen6]

Good conversation with @gwenwindflower @callum-mcdata @MichelleArk in Slack: Could we envision supporting other nested fields / configurations in the future? For example, during community office hours, there was an ask to make "enforcing column order" configurable. I don't think we're going to do that in the first cut—for simplicity, and because I don't think deterministic column order is high-value, and finally because column order necessarily changes to handle schema evolution for incremental models—but still, we could imagine other related configurations existing in the future.

contract:
  enforced: true
  <more_things_in_future>: ...

I prefer contract here to spec, again because it feels more suggestive of the larger feature we're interested in building, even if it's not everyone's idea of what "data contract" means.

[gwenwindflower]

i also like contract in terms of pointing to where this is all headed. data contracts do indeed mean many things to many people, but this is one of the most common meanings.

[aranke]

I disagree with how most data people use contract (should be between two different parties IMHO), but I'm going to commit if that makes things clearer.

[joellabes]

Totally happy with

contract:
  enforced: true
  <more_things_in_future>: ...

!