Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Fix Version/s: 2.0.4
-
Component/s: None
-
Security Level: All
-
Labels:None
Description
Queries like
SELECT COUNT(a)
FROM \a a
WHERE EXISTS (SELECT 0
FROM \b b
WHERE b.a = a)
will not work, whereas they should.
Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Actually, a "LIMIT 1" at the end of the subquery would come in handy here, too.
Doctrine 2 will give an error message
[Syntax Error] line 0, col [...]: Error: Expected known function, got '0''
when parsing the DQL statement.
According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an ArithmeticTerm, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position.
This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation.
Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
Queries like {code} SELECT COUNT(a) FROM \a a WHERE EXISTS (SELECT 0 FROM \b b WHERE b b.a = :a) {code} will not work, whereas they should. Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Doctrine 2 will give an error message [Syntax Error] line 0, col [...]: Error: Expected known function, got '0'' when parsing the DQL. According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an Arithmetic Term, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position. This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation. Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds. |
Queries like {code} SELECT COUNT(a) FROM \a a WHERE EXISTS (SELECT 0 FROM \b b WHERE b.a = :a) {code} will not work, whereas they should. Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Doctrine 2 will give an error message [Syntax Error] line 0, col [...]: Error: Expected known function, got '0'' when parsing the DQL statement. According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an Arithmetic Term, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position. This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation. Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds. |
| Description |
Queries like {code} SELECT COUNT(a) FROM \a a WHERE EXISTS (SELECT 0 FROM \b b WHERE b.a = :a) {code} will not work, whereas they should. Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Doctrine 2 will give an error message [Syntax Error] line 0, col [...]: Error: Expected known function, got '0'' when parsing the DQL statement. According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an Arithmetic Term, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position. This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation. Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds. |
Queries like {code} SELECT COUNT(a) FROM \a a WHERE EXISTS (SELECT 0 FROM \b b WHERE b.a = :a) {code} will not work, whereas they should. Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Doctrine 2 will give an error message [Syntax Error] line 0, col [...]: Error: Expected known function, got '0'' when parsing the DQL statement. According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an ArithmeticTerm, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position. This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation. Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds. |
| Affects Version/s | 2.0.2 [ 10116 ] |
| Description |
Queries like {code} SELECT COUNT(a) FROM \a a WHERE EXISTS (SELECT 0 FROM \b b WHERE b.a = :a) {code} will not work, whereas they should. Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Doctrine 2 will give an error message [Syntax Error] line 0, col [...]: Error: Expected known function, got '0'' when parsing the DQL statement. According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an ArithmeticTerm, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position. This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation. Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds. |
Queries like {code} SELECT COUNT(a) FROM \a a WHERE EXISTS (SELECT 0 FROM \b b WHERE b.a = a) {code} will not work, whereas they should. Assume that there are potentially millions of b's per a, so this should not be joined, just simply left as-is as a correlated subquery within an exists expression. Actually, a "LIMIT 1" at the end of the subquery would come in handy here, too. Doctrine 2 will give an error message [Syntax Error] line 0, col [...]: Error: Expected known function, got '0'' when parsing the DQL statement. According to the EBNF definition, 0 qualifies as a Literal, which qualifies as an ArithmeticPrimary, which qualifies as an ArithmeticFactor, which qualifies as an ArithmeticTerm, which qualifies as a SimpleArithmeticExpression, which qualifies as a ScalarExpression, which qualifies as a SimpleSelectExpression, which should be perfectly legitimate in that position. This is yet another annoying case of the Doctrine 2 documentation not matching the behavior of the actual implementation. Fortunately, it is easy to work around this defect by selecting some field and sacrificing a bit of performance, but then again, it sucks to have to continuously implement workarounds. |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | 2.0.3 [ 10117 ] | |
| Resolution | Fixed [ 1 ] |
| Fix Version/s | 2.0.4 [ 10130 ] | |
| Fix Version/s | 2.0.3 [ 10117 ] |
| Workflow | jira [ 12496 ] | jira-feedback [ 14802 ] |
| Workflow | jira-feedback [ 14802 ] | jira-feedback2 [ 16666 ] |
| Workflow | jira-feedback2 [ 16666 ] | jira-feedback3 [ 18919 ] |