Doctrine 2 - ORM

Discriminator column is not considered correctly for class table inheritance

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Minor Minor
  • Resolution: Won't Fix
  • Affects Version/s: Git Master
  • Fix Version/s: None
  • Component/s: ORM
  • Security Level: All
  • Labels:
    None

Description

Imagine having a class table inheritance for Employee and Person:

class Person {} => is mapped to table "person"
class Employee extends Person {} is mapped to table "person_employee"

When selecting "SELECT e FROM Employee" the SqlWalker will not generate a WHERE condition for a correct discriminator column value (e.g. "employee"). The ORM seems to trust on the generated INNER JOIN (person.id = person_employee.id).

Of course the table person_employee should only contain rows for Employee ojects. But if you have a discriminator value "person" for a row matching an Employee row, the repository will return a Person object although we selected from Employee.

A simple fix is to add the correct DQL expression:
SELECT e FROM Employee WHERE e INSTANCE OF Employee

Is there any reason, why the discriminator column is only considered for single table inheritance explicitly (see https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L426)?

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Alexander added a comment -

Can you provide more information on your usecase and where this leads to wrong results? Unless you're altering the discriminator column values yourself this should be no problem?

Show
Alexander added a comment - Can you provide more information on your usecase and where this leads to wrong results? Unless you're altering the discriminator column values yourself this should be no problem?
Hide
Permalink
Marco Pivetta added a comment -

JTI assumes that your rows in table `person_employee` are part of instances of `Employee`.

If you manually altered the discriminator column, that cannot be helped, since the ORM does not support casting.

Show
Marco Pivetta added a comment - JTI assumes that your rows in table `person_employee` are part of instances of `Employee`. If you manually altered the discriminator column, that cannot be helped, since the ORM does not support casting.
Hide
Permalink
Per Bernhardt added a comment -

Yes, the discriminator column is "manually" altered by our CMS. In other words, our CMS does not care to delete rows in any subtable, it only changes the discriminator column. So a valid solution for this situation is to change that, of course.

But why does the ORM check the discriminator column only for single table inheritance? In other words: Why do we need to have a discriminator column for class table inheritance, if the ORM does not rely on it?

Show
Per Bernhardt added a comment - Yes, the discriminator column is "manually" altered by our CMS. In other words, our CMS does not care to delete rows in any subtable, it only changes the discriminator column. So a valid solution for this situation is to change that, of course. But why does the ORM check the discriminator column only for single table inheritance? In other words: Why do we need to have a discriminator column for class table inheritance, if the ORM does not rely on it?
Hide
Permalink
Marco Pivetta added a comment -

It is used during the hydration step to decide what type your entity is as far as I know, even if all values in the joined tables are NULL.

Show
Marco Pivetta added a comment - It is used during the hydration step to decide what type your entity is as far as I know, even if all values in the joined tables are NULL.
Hide
Permalink
Per Bernhardt added a comment -

Do you think it would break things when checking the discriminator column for class table inheritance in https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L426?

Show
Per Bernhardt added a comment - Do you think it would break things when checking the discriminator column for class table inheritance in https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query/SqlWalker.php#L426?
Hide
Permalink
Marco Pivetta added a comment -

That check is not needed in JTI... And anyway, your logic wouldn't work if your CMS does an upcast somewhere.

Show
Marco Pivetta added a comment - That check is not needed in JTI... And anyway, your logic wouldn't work if your CMS does an upcast somewhere.

People

  • Assignee:
    Benjamin Eberlei
    Reporter:
    Per Bernhardt
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: