Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1900

Impossibility to override built-in SQL functions

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: Git Master
    • Fix Version/s: 2.3
    • Component/s: DQL
    • Security Level: All
    • Labels:
      None
    • Environment:
      Any

      Description

      Doctrine doesn't allow to to create own SQL function for DQL if that function is already defined as "built-in". An example could be custom DATE_ADD implementation.
      Method FunctionDeclaration() in Doctrine\ORM\Query\Parser gives higher priority to built-in SQL functions, even if they are not
      usable for a specific situation, and registering of own datetime function doesn't help. This issue makes it impossible to use some advanced Doctrine extensions,
      for example https://github.com/beberlei/DoctrineExtensions that provide fuller implementations.
      Considering the fact that someone may want to use ready components provided by the community, and being new to Doctrine can't figure out the way to hack
      or workaround this, the issue is a major one.

        Activity

        Alex Oroshchuk created issue -
        Alex Oroshchuk made changes -
        Field Original Value New Value
        Description If someone wants to create own SQL function for DQL (for example custom DATE_ADD implementation) Doctrine doesn't allow to do that.
        Method {{FunctionDeclaration()}} in _Doctrine\ORM\Query\Parser_ gives higher priority to built-in SQL functions, even if they are not
        usable for a specific situation. Registering own datetime function doesn't help either. This issue makes it impossible to use some advanced Doctrine extensions,
        for example https://github.com/beberlei/DoctrineExtensions.
        Considering the fact that someone may want to use ready components provided by the community, and being new to Doctrine can't figure out the way to hack
        or workaround this, the issue is a major one.
        Doctrine doesn't allow to to create own SQL function for DQL if that function is already defined as "built-in". An example could be custom {{DATE_ADD}} implementation.
        Method {{FunctionDeclaration()}} in _Doctrine\ORM\Query\Parser_ gives higher priority to built-in SQL functions, even if they are not
        usable for a specific situation, and registering of own datetime function doesn't help. This issue makes it impossible to use some advanced Doctrine extensions,
        for example https://github.com/beberlei/DoctrineExtensions that provide fuller implementations.
        Considering the fact that someone may want to use ready components provided by the community, and being new to Doctrine can't figure out the way to hack
        or workaround this, the issue is a major one.
        Hide
        Benjamin Eberlei added a comment -

        Just name the method differently.

        Show
        Benjamin Eberlei added a comment - Just name the method differently.
        Benjamin Eberlei made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Won't Fix [ 2 ]
        Hide
        Alex Oroshchuk added a comment -

        To rename the method one has to KNOW that he has to rename it, i.e. to know about this issue.
        One has to SPEND hours (like me) on understanding that there are built-in implementations and other extensions that are meant
        to provide necessary features just don't work. IMHO it's just too cruel to leave it as is.

        As to the renaming: is it ok to go and edit source code (change class name at least) provided by someone else and then merge all the sources when new releases appear?
        Is that the only way flexible Doctrine provides? Also, I want DQL to be as close as possible to real SQL. I don't want to see weird stuff like MY_DATE_ADD or BETTER_DATE_ADD, or whatever it will be.
        Syntax matters, we are all writers, code writers...

        I re-open the issue in order to attract more attention, but you are free to decide how to treat it. Hope you'll find the best solution. A short line in documentation could notify about current limitations and save hours for people
        who want to be productive with Doctrine.

        Show
        Alex Oroshchuk added a comment - To rename the method one has to KNOW that he has to rename it, i.e. to know about this issue. One has to SPEND hours (like me) on understanding that there are built-in implementations and other extensions that are meant to provide necessary features just don't work. IMHO it's just too cruel to leave it as is. As to the renaming: is it ok to go and edit source code (change class name at least) provided by someone else and then merge all the sources when new releases appear? Is that the only way flexible Doctrine provides? Also, I want DQL to be as close as possible to real SQL. I don't want to see weird stuff like MY_DATE_ADD or BETTER_DATE_ADD, or whatever it will be. Syntax matters, we are all writers, code writers... I re-open the issue in order to attract more attention, but you are free to decide how to treat it. Hope you'll find the best solution. A short line in documentation could notify about current limitations and save hours for people who want to be productive with Doctrine.
        Alex Oroshchuk made changes -
        Resolution Won't Fix [ 2 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Benjamin Eberlei added a comment -

        Printing statements in bold isnt helpful. This is open-source.

        However, you are right that this could be more user-friendly. Its now throwing an exception when an internal function is attempted to be overwritten.

        Show
        Benjamin Eberlei added a comment - Printing statements in bold isnt helpful. This is open-source. However, you are right that this could be more user-friendly. Its now throwing an exception when an internal function is attempted to be overwritten.
        Benjamin Eberlei made changes -
        Status Reopened [ 4 ] Closed [ 6 ]
        Fix Version/s 2.3 [ 10185 ]
        Resolution Fixed [ 1 ]
        Benjamin Eberlei made changes -
        Workflow jira [ 13810 ] jira-feedback [ 15694 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 15694 ] jira-feedback2 [ 17558 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 17558 ] jira-feedback3 [ 19816 ]

        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-1900, expand=changesets[0:20].revisions[0:29],reviews}, methodType=GET}] : Received status code 503 (Service Temporarily Unavailable)

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Alex Oroshchuk
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: