[PR #10488] Reject colliding field mapping in STI (need advice) #12399

New Issue

admin · 2026-01-22T16:13:55+01:00

admin commented

2026-01-22 16:13:55 +01:00

Original Pull Request: https://github.com/doctrine/orm/pull/10488

State: closed
Merged: No

When using Single Table Inheritance and two sibling classes declare fields with the same name, but different column definitions (say, one is int, the other one string), the resulting conflict is not raised as a problem.

Current situation

The database schema will be created based on one of the two definitions. In the current example, we actually end up with an INT column. Values can not be persisted correctly, are implicitly cast/converted or lost.

Expected behaviour

The ORM should at least refuse this configuration, clearly pointing out what the problem is, an possibly suggest to use name="..." declarations to make sure different columns for the different fields can co-exist in the database.
The naming strategy (or whatever mechanism) might try to use pre/suffixes automatically to resolve the situation, albeit that would probably be a larger BC break and would cause old schemas to not work anymore.
We might consider to check if the column definitions actually differ and use a single column for two fields in two classes if the definitions match. In the long run, that might be hard to maintain – for example, what should happen once one of the two definitions changes?

Probably the first one is the only feasible solution.

Additional information

Seems to work well for JTI, since different fields end up in different tables and each one gets the right column definition.
Regarding the Schema Tool, ba01175700 made it possible to re-process a column with a name already taken, but changing/removing that line at least does not break any tests. So, I could not figure out why this was needed (at that time).

TODO

Can we throw the exception from a better, more central place like the runtime validation in CMF? Or is the check too expensive and can only be in the Schema Validator?
When checking somewhere where we don't know about the final, resulting schema, the check is more involved. We also need to think about potential conflicts from associations and embeddables.

**Original Pull Request:** https://github.com/doctrine/orm/pull/10488 **State:** closed **Merged:** No --- When using Single Table Inheritance and two sibling classes declare fields with the same name, but different column definitions (say, one is `int`, the other one `string`), the resulting conflict is not raised as a problem. #### Current situation The database schema will be created based on one of the two definitions. In the current example, we actually end up with an `INT` column. Values can not be persisted correctly, are implicitly cast/converted or lost. #### Expected behaviour * The ORM should at least refuse this configuration, clearly pointing out what the problem is, an possibly suggest to use `name="..."` declarations to make sure different columns for the different fields can co-exist in the database. * The naming strategy (or whatever mechanism) might try to use pre/suffixes automatically to resolve the situation, albeit that would probably be a larger BC break and would cause old schemas to not work anymore. * We might consider to check if the column definitions actually differ and use a single column for two fields in two classes if the definitions match. In the long run, that might be hard to maintain – for example, what should happen once one of the two definitions changes? Probably the first one is the only feasible solution. #### Additional information * Seems to work well for JTI, since different fields end up in different tables and each one gets the right column definition. * Regarding the Schema Tool, ba01175700e1f0caf79cef642531fcfdb40478a6 made it possible to re-process a column with a name already taken, but changing/removing that line at least does not break any tests. So, I could not figure out why this was needed (at that time). #### TODO - [ ] Can we throw the exception from a better, more central place like the runtime validation in CMF? Or is the check too expensive and can only be in the Schema Validator? - [ ] When checking somewhere where we don't know about the final, resulting schema, the check is more involved. We also need to think about potential conflicts from associations and embeddables.

admin added the pull-request label 2026-01-22 16:13:55 +01:00

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: doctrine/archived-orm#12399