Fixes DDC-3192
Refs DDC-2494
This is essentially a fix from DDC-2494 applied to SQLWalker.
The issue: type was not converted to PHP value when the result is fetched by
executing DQL query rather than using entity manager's findX(). Similar issue
for BasicEntityPersister (which is used when em's findX is executed) was fixed
in DDC-2494, but SQLWalker made the issue valid for any custom query.
When some dql contains a subselect with expression in parenthesis, the
expression of the $simpleSelectExpression parameter given to
walkSimpleSelectExpression is an instance of AST\ParenthesisExpression.
Before this commit, this case defaulted to
$this->walkEntityIdentificationVariable($expr) where $expr is supposed
to be a string. A fatal error was then yielded.
Without this patch a query would like like:
```
SELECT c0_.Country AS sclr0
FROM Continent c0_ WITH (NOLOCK)
WHERE c0_.Country = 38
GROUP BY sclr0
```
Using the column alias in the GROUP BY clause. However this is not allowed on SQL Server. References:
1. http://stackoverflow.com/a/3841804
2. http://technet.microsoft.com/en-us/library/ms189499.aspx (Logical Processing Order of the SELECT statement)
The correct query should be:
```
SELECT c0_.Country AS sclr0
FROM Continent c0_ WITH (NOLOCK)
WHERE c0_.Country = 38
GROUP BY c0_.Country
```
- Typo in variable name in JoinClassPathExpression;
- Undefined class AST\ArithmeticPrimary (x2);
- QueryException::invalidPathExpression() expects a PathExpression, not a string.
In SqlWalker::walkJoin(), SqlWalker::walkRangeVariableDeclaration() can be
called which may produce an 'ON' clause if the entity inheritance type is
JOINED. As walkJoin() may then produce another ON clause, this results in
invalid SQL (e.g. '... ON foo = bar ON (baz = quux) ...' when the inheritance
type is JOINED.
This adds a test and a fix for the problem, by checking for an inheritance type
of JOINED in walkJoin() and using AND instead of ON in the appropriate place.
It seems like this part of the code is begging to be refactored. This is my
first foray into Doctrine internals and can't see a way to do this without
stomping all over the rest of the code, but this section seems ripe for cleanup
by somebody who is familiar.
