Details

    • Type: Documentation Documentation
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: Git Master
    • Fix Version/s: None
    • Component/s: ORM
    • Security Level: All
    • Labels:
      None
    • Environment:
      mysql-5.6.13-winx64, SQL Server 2012, PHP-5.5.4, Windows 7 64 bits professional

      Description

      The documentation on Class Table Inheritance could use some improvements.

      1. It's not very clear which classes can have an IDENTITY (auto increment). Consider the example parent: Person, child: Employee. Then add another child: Employer. (this scenario assumes of course that an Employer can never be an Employee). When entering 4 Persons the information in the tables could look like this:
      `Parent: (1, Employee), (2, Employee), (3, Employer), (4, Employee) Child Employee: 1,2,4 Child: Employer: 3`
      So that means a child can not have an IDENTITY.

      Suggestion: specify in docs parent can have IDENTITY, children must not have IDENTITY

      2. The parent MUST have an "identifier/primary key" (notice that identifier is not the same as IDENTITY/auto increment). This is not shown in the docs and will throw this:
      `Fatal error: Uncaught exception 'Doctrine\ORM\Mapping\MappingException' with message 'No identifier/primary key specified for Entity "MyProject\Model\Person". Every Entity must have an identifier/primary key.'`

      Suggestion: specify parent must have identifier/primary key, children primary key will be taken from parent class and must not be specified again in child entity.

      3. Is it possible to let a child have it's own identity? And reference the child in the parent table not but the parent's primary key but by a Foreign Key. This blog post here http://blog.liip.ch/archive/2012/03/27/table-inheritance-with-doctrine.html leads me to belief this was once the case (because parent has id and related_id) but perhaps was taken out in later doctrine versions?

      Suggestion: specify pros and cons from implementation with FK and without FK (and/or why this changed in history)

      4. Show Generated SQL to help understanding. For MySQL:
      CREATE TABLE Person (id INT NOT NULL, discr VARCHAR(255) NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
      CREATE TABLE Employee (id INT NOT NULL, PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8 COLLATE utf8_unicode_ci ENGINE = InnoDB
      ALTER TABLE Employee ADD CONSTRAINT FK_A4E917F7BF396750 FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE

      For SQL Server:
      CREATE TABLE Person (id INT NOT NULL, discr NVARCHAR(255) NOT NULL, PRIMARY KEY (id))
      CREATE TABLE Employee (id INT NOT NULL, PRIMARY KEY (id))
      ALTER TABLE Employee ADD CONSTRAINT FK_A4E917F7BF396750 FOREIGN KEY (id) REFERENCES Person (id) ON DELETE CASCADE

      5. Since the parent forces the identity of the child (through a constraint), a child can not manage it's own identity. Which is important to know if you want to merge already existing data. With the constraint on the primary key the database follows very closely the conceptual model in the PHP classes, but looses flexibility on the database schema implementation level. While this could be resolved with a Foreign Key where then you loose strictness of the database and the responsibility shifts back to the application.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Benjamin Eberlei
            Reporter:
            Flip
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: