fix: query w/ scoped all columns, join and where clause #5684
Conversation
confluentinc#5503 This fixes a regression introduced in 0.10. The implications of this are not that it crashes the command runner thread, as the original ticket states. Instead, the implications are that queries a users could previously run will now fail. Existing running queries will not be affected. Affected queries will be any using combining: * A join * with a projection using a scoped 'all columns', e.g. a A.* * with a where clause e.g. ``` SELECT A.*, B.Id FROM A JOIN B ON A.Id = B.userId WHERE A.x < 10; ```
| .filter(s -> !sourceName.isPresent() | ||
| || !s.getSourceName().isPresent() | ||
| || sourceName.equals(s.getSourceName())) |
There was a problem hiding this comment.
To understand the solution, first understand the logical model of the query:
Source A Source B
| |
--------Join---------
|
Where Filter
|
Final Projection
The final SELECT / projection node calls its parent to resolve any select stars. In the case of A.* it passes A as the source name to expand when calling resolveSelectStart.
The parent WHERE filter uses the default impl of the resolveSelectStar method, which just looks for a parent node with a matching source name, if one is provided.
A Join node does not have a source name, i.e. it's neither A or B, so the default resolveSelectStart was ignoring it.
The fix is to change the default method to include any parent node that has no source name, thereby including the parent join node.
There was a problem hiding this comment.
LGTM! Nice catch and thanks for the inline description @big-andy-coates
Description
fixes: #5503
This fixes a regression introduced in 0.10.
The implications of this are not that it crashes the command runner thread, as the original ticket states. Instead, the implications are that queries a users could previously run will now fail. Existing running queries will not be affected.
Affected queries will be any using combining:
e.g.
Such queries now work.
Testing done
Usual
Reviewer checklist