Doctrine 2 - ORM
  1. Doctrine 2 - ORM
  2. DDC-1379

Entity Generator Bug with extended classes

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: 2.3
    • Component/s: None
    • Security Level: All
    • Labels:
      None

      Description

      I'm presently using Doctrine 2 in conjunction with Symfony 2 and have come across a bug with the Entity Generator when I'm extending an abstract class. Here's a minor example to demonstrate (please note, any annotations problems or typos are a result of my typing in this ticket. This isn't an actual example, but does accurately show how to reproduce the issue)

      Foo.php
      abstract class Foo
      {
          /**
           * @Column(name="first_name")
           */
          protected $firstName;
      
           /**
           * @Column(name="last_name")
           */
          protected $lastName;
          /**
           * @ORM\Column(name="is_active", type="boolean")
           */
          protected $isActive;
      }
      
      Bar.php
      /**
       * @Entity
       */
      class Bar extends Foo
      {
          /**
           * @Id
           * @Column(type="integer")
           * @GeneratedValue(strategy="AUTO")
           */
          protected $id;
      
          /**
           * @Column(name="created_at", type="datetime")
           */
          protected $createdAt;
      }
      

      Using a setup similar to the above, where Bar extends Foo, there is an issue with the Generator.

      1) The generator is redeclaring Foo's properties, as private variables, in Bar

      So, opening Bar after running the generator, shows the getters and setters, but shows:
      private $firstName;
      private $lastName;
      private $isActive;

      This causes issues because the properties are being recreated as local versions, and their scope is set to private, conflicted with the more open protected version in the abstract class. To me, they shouldn't be placed in Bar because they're declared as protected in Foo and thus Bar has access to them. Also, when they are placed in Bar, the file formatting is messed up around them, suggesting that they were mis-placed in the file.

      2) This may or may not be a bug (it may be intended behavior), but... I would think that when running the generator, the getters and setters for the protected properties declared in Foo would be placed in Foo, and not placed in the class(es) that extend Foo (in this case, Bar). If I also have a class Baz that extends Foo, then Bar and Baz will now have copies of the same getFirstName(), getLastName(), and getIsActive() methods, which is unneeded. They can be placed in the parent class, and overridden in the subclasses if more/different functionality/behavior is needed by the subclass.

      Hopefully this is a clear example. Please feel free to hit me up for more info!
      --mark

        Activity

        Mark Badolato created issue -
        Mark Badolato made changes -
        Field Original Value New Value
        Description I'm presently using Doctrine 2 in conjunction with Symfony 2 and have come across a bug with the Entity Generator when I'm extending an abstract class. Here's a minor example to demonstrate (please note, any annotations problems or typos are a result of my typing in this ticket. This isn't an actual example, but does accurately show how to reproduce the issue)

        abstract class Foo
        {
            /**
             * @Column(name="first_name")
             */
            protected $firstName;

             /**
             * @Column(name="last_name")
             */
            protected $lastName;
            /**
             * @ORM\Column(name="is_active", type="boolean")
             */
            protected $isActive;
        }

        /**
         * @Entity
         */
        class Bar extends Foo
        {
            /**
             * @Id
             * @Column(type="integer")
             * @GeneratedValue(strategy="AUTO")
             */
            protected $id;

            /**
             * @Column(name="created_at", type="datetime")
             */
            protected $createdAt;
        }

        Using a setup similar to the above, where Bar extends Foo, there is an issue with the Generator.

        1) The generator is redeclaring Foo's properties, as private variables, in Bar

        So, opening Bar after running the generator, shows the getters and setters, but shows:
        private $firstName;
        private $lastName;
        private $isActive;

        This causes issues because the properties are being recreated as local versions, and their scope is set to private, conflicted with the more open protected version in the abstract class. To me, they shouldn't be placed in Bar because they're declared as protected in Foo and thus Bar has access to them. Also, when they are placed in Bar, the file formatting is messed up around them, suggesting that they were mis-placed in the file.

        2) This may or may not be a bug (it may be intended behavior), but... I would think that when running the generator, the getters and setters for the protected properties declared in Foo would be placed in Foo, and not placed in the class(es) that extend Foo (in this case, Bar). If I also have a class Baz that extends Foo, then Bar and Baz will now have copies of the same getFirstName(), getLastName(), and getIsActive() methods, which is unneeded. They can be placed in the parent class, and overridden in the subclasses if more/different functionality/behavior is needed by the subclass.

        Hopefully this is a clear example. Please feel free to hit me up for more info!
        --mark
        I'm presently using Doctrine 2 in conjunction with Symfony 2 and have come across a bug with the Entity Generator when I'm extending an abstract class. Here's a minor example to demonstrate (please note, any annotations problems or typos are a result of my typing in this ticket. This isn't an actual example, but does accurately show how to reproduce the issue)

        <pre>
        abstract class Foo
        {
            /**
             * @Column(name="first_name")
             */
            protected $firstName;

             /**
             * @Column(name="last_name")
             */
            protected $lastName;
            /**
             * @ORM\Column(name="is_active", type="boolean")
             */
            protected $isActive;
        }

        /**
         * @Entity
         */
        class Bar extends Foo
        {
            /**
             * @Id
             * @Column(type="integer")
             * @GeneratedValue(strategy="AUTO")
             */
            protected $id;

            /**
             * @Column(name="created_at", type="datetime")
             */
            protected $createdAt;
        }
        </pre>

        Using a setup similar to the above, where Bar extends Foo, there is an issue with the Generator.

        1) The generator is redeclaring Foo's properties, as private variables, in Bar

        So, opening Bar after running the generator, shows the getters and setters, but shows:
        private $firstName;
        private $lastName;
        private $isActive;

        This causes issues because the properties are being recreated as local versions, and their scope is set to private, conflicted with the more open protected version in the abstract class. To me, they shouldn't be placed in Bar because they're declared as protected in Foo and thus Bar has access to them. Also, when they are placed in Bar, the file formatting is messed up around them, suggesting that they were mis-placed in the file.

        2) This may or may not be a bug (it may be intended behavior), but... I would think that when running the generator, the getters and setters for the protected properties declared in Foo would be placed in Foo, and not placed in the class(es) that extend Foo (in this case, Bar). If I also have a class Baz that extends Foo, then Bar and Baz will now have copies of the same getFirstName(), getLastName(), and getIsActive() methods, which is unneeded. They can be placed in the parent class, and overridden in the subclasses if more/different functionality/behavior is needed by the subclass.

        Hopefully this is a clear example. Please feel free to hit me up for more info!
        --mark
        Mark Badolato made changes -
        Description I'm presently using Doctrine 2 in conjunction with Symfony 2 and have come across a bug with the Entity Generator when I'm extending an abstract class. Here's a minor example to demonstrate (please note, any annotations problems or typos are a result of my typing in this ticket. This isn't an actual example, but does accurately show how to reproduce the issue)

        <pre>
        abstract class Foo
        {
            /**
             * @Column(name="first_name")
             */
            protected $firstName;

             /**
             * @Column(name="last_name")
             */
            protected $lastName;
            /**
             * @ORM\Column(name="is_active", type="boolean")
             */
            protected $isActive;
        }

        /**
         * @Entity
         */
        class Bar extends Foo
        {
            /**
             * @Id
             * @Column(type="integer")
             * @GeneratedValue(strategy="AUTO")
             */
            protected $id;

            /**
             * @Column(name="created_at", type="datetime")
             */
            protected $createdAt;
        }
        </pre>

        Using a setup similar to the above, where Bar extends Foo, there is an issue with the Generator.

        1) The generator is redeclaring Foo's properties, as private variables, in Bar

        So, opening Bar after running the generator, shows the getters and setters, but shows:
        private $firstName;
        private $lastName;
        private $isActive;

        This causes issues because the properties are being recreated as local versions, and their scope is set to private, conflicted with the more open protected version in the abstract class. To me, they shouldn't be placed in Bar because they're declared as protected in Foo and thus Bar has access to them. Also, when they are placed in Bar, the file formatting is messed up around them, suggesting that they were mis-placed in the file.

        2) This may or may not be a bug (it may be intended behavior), but... I would think that when running the generator, the getters and setters for the protected properties declared in Foo would be placed in Foo, and not placed in the class(es) that extend Foo (in this case, Bar). If I also have a class Baz that extends Foo, then Bar and Baz will now have copies of the same getFirstName(), getLastName(), and getIsActive() methods, which is unneeded. They can be placed in the parent class, and overridden in the subclasses if more/different functionality/behavior is needed by the subclass.

        Hopefully this is a clear example. Please feel free to hit me up for more info!
        --mark
        I'm presently using Doctrine 2 in conjunction with Symfony 2 and have come across a bug with the Entity Generator when I'm extending an abstract class. Here's a minor example to demonstrate (please note, any annotations problems or typos are a result of my typing in this ticket. This isn't an actual example, but does accurately show how to reproduce the issue)

        {code:title=Foo.php|borderStyle=solid}
        abstract class Foo
        {
            /**
             * @Column(name="first_name")
             */
            protected $firstName;

             /**
             * @Column(name="last_name")
             */
            protected $lastName;
            /**
             * @ORM\Column(name="is_active", type="boolean")
             */
            protected $isActive;
        }
        {code}

        {code:title=Bar.php|borderStyle=solid}
        /**
         * @Entity
         */
        class Bar extends Foo
        {
            /**
             * @Id
             * @Column(type="integer")
             * @GeneratedValue(strategy="AUTO")
             */
            protected $id;

            /**
             * @Column(name="created_at", type="datetime")
             */
            protected $createdAt;
        }
        {code}

        Using a setup similar to the above, where Bar extends Foo, there is an issue with the Generator.

        1) The generator is redeclaring Foo's properties, as private variables, in Bar

        So, opening Bar after running the generator, shows the getters and setters, but shows:
        private $firstName;
        private $lastName;
        private $isActive;

        This causes issues because the properties are being recreated as local versions, and their scope is set to private, conflicted with the more open protected version in the abstract class. To me, they shouldn't be placed in Bar because they're declared as protected in Foo and thus Bar has access to them. Also, when they are placed in Bar, the file formatting is messed up around them, suggesting that they were mis-placed in the file.

        2) This may or may not be a bug (it may be intended behavior), but... I would think that when running the generator, the getters and setters for the protected properties declared in Foo would be placed in Foo, and not placed in the class(es) that extend Foo (in this case, Bar). If I also have a class Baz that extends Foo, then Bar and Baz will now have copies of the same getFirstName(), getLastName(), and getIsActive() methods, which is unneeded. They can be placed in the parent class, and overridden in the subclasses if more/different functionality/behavior is needed by the subclass.

        Hopefully this is a clear example. Please feel free to hit me up for more info!
        --mark
        Benjamin Eberlei made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 2.3 [ 10185 ]
        Resolution Duplicate [ 3 ]
        Benjamin Eberlei made changes -
        Workflow jira [ 13022 ] jira-feedback [ 15028 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback [ 15028 ] jira-feedback2 [ 16892 ]
        Benjamin Eberlei made changes -
        Workflow jira-feedback2 [ 16892 ] jira-feedback3 [ 19145 ]

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Mark Badolato
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: