get_select() TSQL compatibility about dbt-expectations HOT 4 CLOSED

Hi @swanderz ! That is indeed a bit obtuse. The idea was to be able to test grouped expressions across multiple models. So, say you wanted to test counts by order_date across two models, you could group on order_date. And unfortunately, I don't think this group_by feature is actually used by any of the expectations in this package (yet), so there's no good example, although I use equal_expression directly in one of my project this way.

Rather than conditionally grouping when there is a group_by being passed, I simply always group the expression. The default is simply a string col which acts as a dummy grouping variable. This works fine on all the platforms I've been testing.
However, if T-SQL barfs on this, you could probably override get_select (which is already an adapter macro) and only actually group when there is a non-default grouping value. I'd also be happy to help update the default version to be more explicit when there is no grouping. Does that make sense?

from dbt-expectations.

Just looking through the code again, I also use this fake column to join the two expression results. So, if there are no columns to group by and you just have two scalar results, like counts for example, I can still join and compare the two without having to change the join type to a cross join.

from dbt-expectations.

@swanderz take a look at #63 to see if that makes more sense. It's just a quick take on making this more explicit. Btw, there are a couple of direct integration tests against equal_expression that take advantage of group_by.

Does a cross join b work in T-SQL, or do you do a, b there?

from dbt-expectations.

In T-SQL a cross join b should work fine, yes

from dbt-expectations.