Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-878

Don't explicitly require object members (fields) to be defined in the entity class

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None

      Description

      Currently, Doctrine REQUIRES that a given entity class have protected or private members explicitly defined in the class (even if meta data mapping is handled elsewhere, such as in YAML). This is less than optimal...for example, many class implementations prefer to store all data in a protected $fields member, as an array, accessing the members with getters and setters.

      Doctrine makes this behavior impossible. An exception is thrown if a field defined in meta data is not an explicit member of the class. Instead, it should 'take the meta data's word for it' that the field exists, and is accessible via getters and setters, without explicitly checking for the member. The meta data is already the authoritative source, I don't see why the double check should (or needs to) be performed (although I am not familiar with Doctrine internals). Since Doctrine recommends making members private, I have to assume it is already hydrating them with the get/set accessors anyway...so it should just rely on them.

      Quick example use case (notice 'name' is not actually a member...it is stored in $fields and assume meta data is defined in a separate yaml file):

      class User

      { protected $fields = array(); public function getName() { return $this->fields['name']; } public function setName($name) { $this->fields['name'] = $name; } }

        Activity

        Nick Daugherty created issue -
        Hide
        Benjamin Eberlei added a comment -

        This maybe a potential optimization for a very future version. However currently we heavily rely on the Reflection support for properties, which kind of makes a change of this a very complex undertaking.

        Show
        Benjamin Eberlei added a comment - This maybe a potential optimization for a very future version. However currently we heavily rely on the Reflection support for properties, which kind of makes a change of this a very complex undertaking.
        Roman S. Borschel made changes -
        Field Original Value New Value
        Priority Major [ 3 ] Minor [ 4 ]
        Benjamin Eberlei made changes -
        Workflow jira [ 12104 ] jira-feedback [ 13883 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 13883 ] jira-feedback2 [ 15747 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 15747 ] jira-feedback3 [ 18004 ]

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

          People

          • Assignee:
            Roman S. Borschel
            Reporter:
            Nick Daugherty
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: