Kirk Haselden

Expressions: Part III

Jamie's blog got me thinking about expressions and wanted to give some background and a little more information about how they work.

Background

Property expressions came relatively late in the development cycle. There was always an idea floating around on our team about putting expressions on properties. Even though it seems obvious now, it wasn't obvious to us early on how to do it. In fact, we visited the idea on several occasions, never coming to a decent approach or design. Very early on, we didn't even have the notion of an expression evaluator in the runtime at all. Even though we were writing one for the derived column and conditional split, we didn't make the conceptual leap as soon as we might have that we could use the expression evaluator for the runtime as well. Eventually, Sergei Ivanov and I were sitting in my office trying to solve the long time problem, how to replace property mappings with a more workable and manageable solution. We knew we wanted to use expressions somehow. By this time, we'd incorporated them into the variables, on the forloop and into precedence constraints. The problem was, how to do it in a way that would successfully apply the result at the right time. Sergei said something about applying them at execution time and then we realized we were on to something.

How They Work

The trick is “applying“ the result of the expressions at the right time. For tasks, that meant right before initialization, validation, and execution. For other objects, the key edge events are different. Here's when expressions are applied.

• Tasks
• Before Saving
• After Loading
• Before initialization
• Before Validation
• Before Execution
• Connection Managers
• Before Saving
• After Loading
• Before initialization
• Before returning from AcquireConnection calls
• Log Providers
• Before Saving
• After Loading
• Before Initialization
• ForEach Enumerators
• Before Saving
• After Loading
• Before Initialization
• Before returning from GetEnumerator calls

These object types are “hosted“. That means there is a host that is, for the most part, transparent in the designer that creates the component and wraps it. The hosts do a lot of stuff for the components so the components don't have to do it themselves. This factors out functionality to a centralized place and eliminates the need for custom component writers to re-implement all that code. Property expressions are one of those features implemented on the hosts. The host examines the components when it loads it the first time and discovers things like what properties the component exposes etc. It also tracks the property expressions that you create on the component and “applies“ the expression to the property or in other words, evaluates the expression and sets the corresponding property for the expression to the resulting value.

Hopefully, this helps you better understand the behavior of property expressions. As shown in previous blogs, property expressions are an extremely powerful way to dynamically modify package behavior based on various package external and internal parameters.

Hope this helps,

Thanks,

Universe.Earth.Software.Microsoft.SQLServer.IS.KirkHaselden