Uploaded image for project: 'Doctrine 2 - ORM'
  1. Doctrine 2 - ORM
  2. DDC-878

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


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


      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; } }



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


            • Created: