markproctor1

@Fleid It would be better named if it weren't listed as incremental, but some of the other behaviors of table materialization such as potentially dropping / replacing the table are...

@Fleid What goes into the decision to make it a switch rather than an optional part of table materialization? Someone out there probably LOVES the fact that their tables get...

This is intuitive to me: {{ config(materialized='table', insert_overwrite=true) }} However, "insert overwrite" as a concept can be full load or incremental: https://docs.getdbt.com/reference/resource-configs/glue-configs#the-insert_overwrite-strategy > If no partition_by is specified, then the...

Totally agree, no need to be clever here. In our case we'd actually prefer to know if the table schemas don't line up, fast failure rather than handling the schema...

@Fleid I'm trying to decide when to fit this in, as sprint work or on the side. I am interested, will get back to you asap.

@jtcohen6 Your comment makes sense about seeds, but I don't know enough to say whether it should be in scope here. Regarding table models: Do you expect `materialized='table', overwrite=true` to...

@Fleid Our teams are discussing this again. We're finding the benefit of INSERT OVERWRITE in our custom materialization isn't worth the extra dev/maintenance time through table schema changes. So as...

@dataders No, I was unclear! We want it more than ever but think it should be handled as a table materialization instead of an incremental materialization.

I'd like programmatic access to macro properties, so I can make a list of macros based on their folder location.

Folder-level configs would make a huge difference on my project. With 50+ developers and growing we don't want anyone to modify project-level files day-to-day, but we do want them to...