Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1079

Behavior of Doctrine 2 is not as defined by EBNF definition for SimpleSelectExpression

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor 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

        Daniel Alvarez Arribas created issue -
        Daniel Alvarez Arribas made changes -
        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.
        Daniel Alvarez Arribas made changes -
        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.
        Daniel Alvarez Arribas made changes -
        Affects Version/s 2.0.2 [ 10116 ]
        Daniel Alvarez Arribas made changes -
        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.
        Hide
        Benjamin Eberlei added a comment -

        Fixed, didn't work because of a shortcut that was implemented in SimpleSelectExpression. I removed that now and fixed the problem the shortcut was trying to fix at a better location.

        Show
        Benjamin Eberlei added a comment - Fixed, didn't work because of a shortcut that was implemented in SimpleSelectExpression. I removed that now and fixed the problem the shortcut was trying to fix at a better location.
        Benjamin Eberlei made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.0.3 [ 10117 ]
        Resolution Fixed [ 1 ]
        Benjamin Eberlei made changes -
        Fix Version/s 2.0.4 [ 10130 ]
        Fix Version/s 2.0.3 [ 10117 ]
        Hide
        Benjamin Eberlei added a comment -

        Some more stuff is fixed in regard to this in some lsat ocmmits.

        Show
        Benjamin Eberlei added a comment - Some more stuff is fixed in regard to this in some lsat ocmmits.
        Benjamin Eberlei made changes -
        Workflow jira [ 12496 ] jira-feedback [ 14802 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 14802 ] jira-feedback2 [ 16666 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 16666 ] jira-feedback3 [ 18919 ]

        This list may be incomplete, as errors occurred whilst retrieving source from linked applications:

        • Request to http://www.doctrine-project.org/fisheye/ failed: Error in remote call to 'FishEye 0 (http://www.doctrine-project.org/fisheye/)' (http://www.doctrine-project.org/fisheye) [AbstractRestCommand{path='/rest-service-fe/search-v1/crossRepositoryQuery', params={query=DDC-1079, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Daniel Alvarez Arribas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: