How does CALCULATE know which rows to aggregate based on the table returned by the FILTER function?

[tbennett93]

My question is regarding how the CALCULATE function is able to 'know' which results to aggregate over based on the table that is returned by the FILTER function. 

-CALCULATE takes a filter argument

-The FILTER function returns a table

-The FILTER function can be used for this argument 

thus:

-CALCULATE works by accepting a table as its argument (as this is the return type of the FILTER function). But how does this work?

Take the below example (this is used for example purposes and may not be best practice):

=CALCULATE( Sales , FILTER( ALL('Customer'[Name]), 'Customer'[Name] = "John"))

The ALL function returns a single column: 'Customer'[Name] and then the FILTER function filters all results by "John". This means that the table returned by the FILTER function would simply be a single column table filled only with the name "John". How is this table then used by the CALCULATE function as the filter argument? It's just a table of a single column of duplicate values.

I'm assuming it doesn't simply work by evaluating the output of the FILTER argument as this wouldn't make any sense, given the example above. Instead it must evaluate the FILTER expression as a whole and be aware of the context and filtered content of the FILTER function, rather than simply accepting the output of it?

This question was raised as a result of trying to understand the PREVIOUSDAY/PREVIOUSMONTH functions as they too only return a single-column table of dates; which makes no sense when isolated. These too must somehow communicate with the CALCULATE function in how they're evaluated. 

[johnt75]

The SQLBI guys have a ton of useful information, both in articles and videos . I can also thoroughly recommend their courses on mastering DAX and data modelling.

[johnt75 · Accepted solution]

Its all to do with data lineage. When passing a table to CALCULATE, whether it be multiple columns or a single column, CALCULATE knows which columns in the model that refers to, either because it is directly from those columns or you have used TREATAS to explicitly tell it.

Because it knows which columns they are, the filter is applied to those columns and will then trickle around the model according to the relationships which have been set up.

In the PREVIOUSDAY example, the column of dates which is passed in to the function is typically from the date table, and that is often set up to filter the fact tables, so that any filters applied to the date table will automatically pass down to the fact tables.

[tbennett93]

Thanks for the response. Interesting that CALCULATE just knows which results have been filtered. I feel like this should be mentioned somewhere as I can imagine if I was trying to create DAX based purely on the documentation given the parameters/return types etc, this sort of thing would trip me up.

Is there anywhere I could learn more about this subject (data lineage etc)? It's not something I've ever come across.