We're updating the issue view to help you get more done. 

QueryModel does not correctly propagate subquery identifiers in GroupJoin scenarios


Given a GroupJoin query like:

We get this QueryModel:

Note the highlighted QSRE, which does not correspond to the outer query source ([c]) but rather the sub-query of the main from clause.


Fabian Schmied
January 5, 2017, 4:00 PM

I've analyzed this issue and the problem is that GroupJoinExpressionNode instantiates a helper JoinExpressionNode in it's constructor, passing in the current source expression node to that helper JoinExpressionNode. Later, when the QueryModel is built using Apply, a subquery is introduced and the source is changed to a new MainExpressionNode holding that subquery (due to the Take), but the JoinExpessionNode doesn't see this new source.

I've pushed a spike fix to the internal Git repository, see 28d38fbb9a536d0295fc1f3d1249356d6c34a421 (spike/RMLNQ-105-Possible-Fix) - please check it out.

In the long run, the mutation performed by MethodCallExpressionNodeBase.WrapQueryModel should probably be replaced by a more stable mechanism - it's just too easy to introduce a bug by relying on the source node being parsed into the ctor.

Michael Ketting
January 10, 2017, 3:54 PM

Thanks for the solution!

For backwards compatibility we will also be needing (the option object, will be passed into MethodCallExpressionParseInfo) to allow for explicit enabling of this bugfix.

Michael Ketting
January 13, 2017, 9:07 AM

This property will also be affected by the bugfix since it returns the QuerySource value as it was during initialization of the ExpressionNode. The probably least-breaking update to this would be to leave this behavior as-is, but add an ObsoleteAttribte notifying the user of this discrepancy in the behavior. By going this route, we don't need the options-object for this bugfix.

Michael Ketting
March 3, 2017, 7:05 AM


Michael Ketting


Michael Ketting




Fix versions

Affects versions