Add where parameter to union_relations

[LewisDavies]

Resolves #464, resolves #382

This is a:

• bug fix PR with no breaking changes — please ensure the base branch is main
• new functionality — please ensure the base branch is the latest dev/ branch
• a breaking change — please ensure the base branch is the latest dev/ branch

Description & motivation

I often want to add basic filters when using union_relations, such as excluding obsolete records or low-quality data. Currently, I have to create two models to do so: one to union the data then another to filter it. This PR adds a where parameter to union_relations so models are filtered before being unioned.

More context & discussion can be found in #464 and #382.

Checklist

• I have verified that these changes work locally on the following warehouses (Note: it's okay if you do not have access to all warehouses, this helps us understand what has been covered)
  • BigQuery
  • Postgres
  • Redshift
  • Snowflake
• I have updated the README.md (if applicable)
• I have added tests & descriptions to my models (and macros if applicable)
• I have added an entry to CHANGELOG.md

[dbeatty10]

Thanks for submitting this and for including both integration tests plus documentation 🏆

Thank you also for alerting about the branch names within the merge request template being out-of-date; those are updated now.

Review

Only feedback:

• I'd like to move the where parameter to be at the end of the argument list so we can guarantee no accidental breakage for any consumers.

Is there any reason why it would be beneficial or necessary to be the first keyword argument?

Question:

• It looks like the same filter specified by the where parameter will be applied to every relation; I'm assuming you haven't needed unique filters per relation as often?

Aside

At first, I was wondering if this would conflict or overlap with the where config, but it looks like it is only for test resources.

[LewisDavies]

@dbeatty10 Thanks for the feedback! I've made the changes and tests are passing.

I rebased locally onto next/minor, pushed my changes, and changed the target branch. Should I go ahead and update CHANGELOG.md too?

[dbeatty10]

@dbeatty10 Thanks for the feedback! I've made the changes and tests are passing.

I rebased locally onto next/minor, pushed my changes, and changed the target branch. Should I go ahead and update CHANGELOG.md too?

Sorry for the dramatic delay in conversation @LewisDavies

Could I bother you for two more changes and then we can merge this in?

1. Rebase to main -- we just switched to all pull requests basing off main for simplicity sake
2. Yes, go ahead and update CHANGELOG.md within the "Unreleased" section.

If you don't have the time, just let me know and I can do those two steps too.

Thank you so much for your detailed solution on this!

[LewisDavies]

@dbeatty10 No worries, the changes are all done. Since I rebased off main I updated the target branch too.

With all my testing and rebasing the commits were an absolute mess, so I cleaned them up and force pushed again. Should be good to go now!

[dbeatty10]

Looks awesome, @LewisDavies ! This rocks 🎸