b

User-defined functions are valuable resources for DAX developers. By creating functions, developers can compartmentalize model code into smaller, manageable segments that facilitate independent testing and debugging. After thorough validation and optimization, each function becomes a building block that contributes to the overall robustness of the project.

Functions can be used to share a common business logic within a semantic model, as well as between different models. You can get libraries of DAX user-defined functions at https://daxlib.org/,

To avoid confusion, we always use Pascal case for user-defined functions.

When defining parameters, we have the option to choose the parameter type, subtype, and parameter-passing mode. The most crucial detail is the parameter-passing mode; we dedicate a specific section to this topic later on in the chapter. There are two parameter-passing modes, and the choice of parameter-passing mode significantly impacts the function’s behavior. In contrast, the parameter type and subtype are less relevant. The parameter-passing modes are: VAL: Short for Value. Indicates a parameter that is evaluated before the function call, in the evaluation context of the caller. A VAL parameter has a single and well-defined value during the execution of the function body. Multiple evaluations of the same parameter always produce the same result. EXPR: short for Expression. Indicates a parameter that is an expression, evaluated in the evaluation context where it is being used in the function body. Multiple evaluations of an EXPR parameter may (and oftentimes do) lead to different results.

Recursion or mutual recursion is not supported.

Optional parameters are not supported.

Although UDFs can be used in live connect or composite models, there is no IntelliSense support.

References to a tabular model object (e.g. measure, table, column) in a UDF are not automatically updated when those objects are renamed. If you rename an object that a UDF depends on, the function body will still contain the old name. You must manually edit the UDF expression to update all references to the renamed object.

Two flavors of Direct Lake: Direct Lake on SQL endpoint is the “legacy” version of Direct Lake

Direct Lake on OneLake is a new mode that will be integrated with OneLake security.

model in Direct Lake is always stored on the cloud, and it does not store anything on the local computer. However, this integration opens up the possibility of using external tools and simplifies the introduction of other features, like the next one.

Composite models with Direct Lake and Import mode

you can mix tables in Direct Lake mode (also coming from different sources) and in Import mode.

does not create “limited” relationships between tables from different data sources

The table in Import mode does not have the current limitations of tables in Direct Lake

ill be possible to materialize a view on Lakehouse using SQL statements

: It will also be possible to create calculated tables and calculated columns based on tables connected through Direct Lake.

The semantic model will introduce the notion of “Calendars

The last announcement is the more important one for the long term. You will be able to write and use functions defined in DAX. These are called User-Defined Functions (UDFs), which you should not confuse with User Data Functions in Azure: the DAX UDFs exist in semantic models, are written, and can be consumed in DAX.