Credit goes to Jack van Galen for fixing this issue.
Fix for JoinedSubclassPersister, multiple inserts with versioning throws
an optimistic locking exception.
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
```
The already existing follow-up check throwing "Not all identifier properties can be found in the ResultSetMapping: %s" is a much more technical description.
If $sqlIdentifier is empty (count 0) it can be concluded that there are no mapped results. An alternative error message could thus be "The Paginator does not support queries without mapped results." (line 153).
Possibly '!=' on line 154 could be replaced by '>' because i think this is the only situation that can occur. But since i don't know this for sure, i left it like i found it.
Didn't use elseif in this commit as per Stof his suggestion.
The already existing follow-up check throwing "Not all identifier properties can be found in the ResultSetMapping: %s" is a much more technical description.
If $sqlIdentifier is empty (count 0) it can be concluded that there are no mapped results. An alternative error message could thus be "The Paginator does not support queries without mapped results." (line 153).
Possibly '!=' on line 154 could be replaced by '>' because i think this is the only situation that can occur. But since i don't know this for sure, i left it like i found it.
All func_get_args() calls have been moved to the top of the methods
because HHVM doesn't keep a copy of the original args for performance
reasons.
See facebook/hiphop-php#1027 for details.
