[5.5] Add support to use subqueries as a where condition on a join clause #21008
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As reported on issue #19695 when a user tries to use a
->whereIn()
or a->whereExists()
with a sub-query in a join clause, the query builder does not build the inner query where condition as expected.Example:
Generates this SQL statment:
instead of the expected one:
The is caused due to
JoinClause@newQuery()
method override returns a newJoinClause
instance instead of a QueryBuilder
instance. This makesGrammar@concatenateWhereClauses()
to compile the nested query where clause not as expected.I tried to change
JoinClause@newQuery()
method override to return a QueryBuilder
instance. But doing so fails the nested where tests within a join clause.This PR adds a protected method on the Query Builder that returns a new
Builder
instance for sub-queries so that theJoinClause
class can override it properly.Tests were added to cover these additional cases.