Instruct users to explicitly override `view` and `incremental` materializations about dbt-data-reliability HOT 4 CLOSED

Closing this issue for now, we'll follow up on the issue above.
Thanks!

from dbt-data-reliability.

Hey @jtcohen6 ,
Thanks for the heads up!

It sounds like a reasonable change.
Out of curiosity, did you get complaints from users about it?
We have thousands of users and very few users ever asked us something about it.

About your proposal -
Changing the documentation will certainly work for new installs of the package.
However, existing users will experience the functionality breaking without a version update of Elementary.
Do you plan to notify about this change in your release notes?
Could you mention explicitly the packages that override materializations for users to know the change is relevant for them?

Do you have any other thoughts on how we can update the existing users?
Ideally, I would want an info message on the console saying Note that package XXXX has it's own version of table materialization. To leverage it, use the flag.... like the info message you added for the 1.6 and 1.7 users.

from dbt-data-reliability.

Hey, @jtcohen6 ,
Just to add on top of @Maayan-s 's comment above, this change also seems to affect the test materialization, which a significant part of our package's testing capabilities relies on.

I've noticed that you mentioned this in your docs:

In the future, we may extend the project-level [dispatch configuration](https://docs.getdbt.com/reference/project-configs/dispatch-config) to support a list of authorized packages for overriding built-in materialization.

Would you be open to us contributing this feature?
I think this can significantly ease the setup changes required from our users (compared to every user having to override materializations)

from dbt-data-reliability.

@Maayan-s @haritamar Thanks for the quick responses!

Yes, some users pointed out to us that it was surprising to have materializations overridden simply by installing the package, without explicit opt-in. I still want to preserve the possibility of this behavior, but it shouldn't be something that happens implicitly & by default.

I appreciate this will require some action from end users regardless, and I'm open to a change in dbt-core that minimizes the amount of work that users need to do directly.

Would you be open to us contributing this feature?

Yes. I've opened an issue in dbt-core, please comment there:

• dbt-labs/dbt-core#10090

I'll want to pass this by some of the Core engineers (tomorrow), but once we're aligned on next steps, we can try to include this work as a fast-follow

from dbt-data-reliability.