Hi. I have an Entity called EntityX. EntityX contains a property called FieldX.

During UPDATE in UnitOfWork2, I can add an Expression to FieldX as follows:

CommonEntityBase EntityX = FetchEntity(); // Want to FetchEntity from Database
Expression expression = new Expression(EntityX.Fields["FieldX"], ExOp.Add, 5);
EntityX.Fields["FieldX"].SetExpression(expression);
SaveEntity();

This statement is allowed to set but it ended as StackOverflow when UPDATE.

But, if write like this

CommonEntityBase  EntityX = FetchEntity();
EntityX.Fields["FieldX"].SetExpression(EntityXFields.Add(5));
SaveEntity();

This is working.

Not sure why does it now let caller to do this. Thank you.

The first adds the same field instance in the expression and assigns that expression to that field, the second creates a new field instance (of the same field) and adds that to the expression, so there's no cyclic reference with itself

Otis wrote:

The first adds the same field instance in the expression and assigns that expression to that field, the second creates a new field instance (of the same field) and adds that to the expression, so there's no cyclic reference with itself

I see. Basically, the first one is doing a bit like recursive adding the value to itself. But both are IExpression, wanted to dynamically set the Field inside this "Field + 6" expression, not the bottom one 🤔.

The way to look at it is: you have a field instance F (so an object), and you want to assign an expression to that field. If you create an expression object and use F as the field object, and then assign that expression to F, then, when F's evaluated by the runtime, the expression is seen and the expression is being evaluated: the field in the expression, F, has an expression on it , so that's evaluated and so on, which is what creates the stack overflow.

If you create a new field instance for the expression, of the same type as F, you won't get that issue and therefore the second option you posted works.