Failing test for GH8443

[piowin]

A test suit for #8443.

Closes #8443

[greg0ire]

The same problem appears if you add WITH condition to the joined entity with discriminator

As opposed to what? #6812 is also about WITH, so I'm confused…

[piowin]

The same problem appears if you add WITH condition to the joined entity with discriminator

As opposed to what? #6812 is also about WITH, so I'm confused…

You're right. In both issues the problem was a result of using a with condition. I think the code of SqlWalker::walkJoinAssociationDeclaration could be simplfy a little and the #8443 wouldn't be necessary, but then the code doesn't pass some tests of the SelectSqlGeneratorTest, even though the sql syntax is correct.

[greg0ire]

I'll rephrase my question: what is the difference between both issues? Since the first patch did not fix the second issue, there must be some difference somewhere, right?

[piowin]

The sqls are generated in different methods with different logic.

[greg0ire]

Ok, why is that?

[piowin]

I haven't designed the SqlWalker, but I see that, in the terms of the EBNF of DQL, the logic of the generation of Join is more complex when we join JoinAssociationDeclaration than when we join RangeVariableDeclaration . Some of the logic is similar and maybe it would be possible to put that logic in a separate method.

[greg0ire]

when we join JoinAssociationDeclaration than when we join RangeVariableDeclaration

Ah, so that's the difference! How do each of these look like in DQL?

[piowin]

A JoinAssociationDeclaration is a path to an entity's field (the field can be a collection of entities, a single entity or a simple state field) plus an alias: p.friend AS f (p must be defined before and that's one of the differences with the next one).

A RangeVariableDeclaration is a path to a class plus an alias: \MyNamespace\Person AS p. A RangeVariableDeclaration is the obligatory component that must be placed immediately after the "FROM" clause.

A JoinAssociationDeclaration can be only used as a joined component while A RangeVariableDeclaration can be used as a joined component and a starting point/base of an IdentificationVariableDeclaration which is a building block of the "FROM" clause.

How does the method responsible for generating joins work?
When the sql for a Join is being generated, if the Join is a JoinAssociationDeclaration, it simply delegates to the method that is responsible for generating JoinAssociationDeclaration, that's all. But if the Join is a RangeVariableDeclaration, it generates optional conditions for the RangeVariableDeclaration, like a filter condition, a "with" condition or a discriminator condition. The generation of each conidtion has its unique logic. Also the sql for the RangeVariableDeclaration is being generated by the method that is responsible for that (the method is invoked also when we genarate IdentificationVariableDeclaration, see above). The conditions are added to the sql and the result is returned.

The logic of the generation of the optional brackets (the subject of our discussion) is put in the method that is reponsible for generating JoinAssociationDeclaration, if the Join is a JoinAssociationDeclaration, and is put in the method that is responsible for generating joins, if the Join is a RangeVariableDeclaration.

[greg0ire]

Very clear! Thank you!

[greg0ire]

Thanks @piowin!