ExpressionMutator

[Giacomo Tesio]

Tring to organize the work needed to make the QueryCache useful by allowing each InputParameterExpression to update it's own values from the updated expression, I encountered the ExpressionMutatorFactory and all the IMutableExpression implementations.

This is something I could not understand yet, about the DbLinq internals.

Why we need them?

I need to understand this, since to allow the closure to be updated via a delegate taking the expression (if not the ExpressionChain), I need to pass a lambda between the analizing method expressing how to reach the current analized expression from the initial one.

Defining such a lambda should not be difficult by itself, but the ExpressionMutatorFactory make it harder.


Giacomo

[Pascal Craponne]

In its different steps, DbLinq:

- replaces language specific expressions (VB specific expressions, for example, are changed to standard expressions)

- creates temporary expressions (such as tables, columns, etc.)

- and optimizes some of them (all constant subexpressions are reduced to a single constant value).

For all three steps, the expression tree needs to be updated, this is why there is an ExpressionMutator. And because Expressions are immutable, we needed to create new mutated expressions from old ones.

[Giacomo Tesio]

Stepping that code, it seem to me that many expression visits are done for each query (even if not always of the same expression tree), is this true?

Wouldn't be possible to use a single pass (that probably would require less time, allowing to remove the cache)?
To handle different trees (like the VB ones) couldn't we use different analizers?
Moreover are we sure that optimization don't take too much time (ehm... and what are constant subexpressions? :-D)


I think that, if we could leave Expression unmuted, we would gain a very big performance advantage.


That said, supposing we need to keep the current process, the updated closure values are in the original compiler produced tree.
To not add another expression tree visit (even if it would probably be a lot faster since it should only handle inputparameterexpressions), we should be able to keep track of the current tree node analized: how would you do to pass such info among transformated expressions?


Giacomo