[PR #10454] Failing test: Re-configured protected property not rejected #12374

New Issue

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

admin commented

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

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

State: closed
Merged: No

This has been merged through #10455.

This test case demonstrates two situations where an entity inherits from another entity or a mapped superclass. Both (parent and child) classes have a protected property named field. In other words, the child class overwrites the property and re-configures the mapping information.

The ClassMetadataFactory and other components were not designed to work with such a configuration. Just imagine a situation where an entity base class configures this field on one way, and a subclass in different way – let's say the subclass uses another name for the database column. How should the ORM work with this configuration when using STI or JTI, when querying entities through the root or a leaf class?

The exception rejecting this kind of configuration has been present since the early days:

70477d81e9/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php (L2724)

However, due to quirks in the mapping drivers (see #10417), the duplicated field was never reported to the ClassMetadataFactory, and due to a missing test case for the mis-configuration, this was never noticed.

**Original Pull Request:** https://github.com/doctrine/orm/pull/10454 **State:** closed **Merged:** No --- This has been merged through #10455. <hr> This test case demonstrates two situations where an entity inherits from another entity or a mapped superclass. Both (parent and child) classes have a protected property named `field`. In other words, the child class overwrites the property and re-configures the mapping information. The `ClassMetadataFactory` and other components were not designed to work with such a configuration. Just imagine a situation where an entity base class configures this field on one way, and a subclass in different way – let's say the subclass uses another `name` for the database column. How should the ORM work with this configuration when using STI or JTI, when querying entities through the root or a leaf class? The exception rejecting this kind of configuration has been present since the early days: https://github.com/doctrine/orm/blame/70477d81e96c0044ad6fd8c13c37b2270d082792/lib/Doctrine/ORM/Mapping/ClassMetadataInfo.php#L2724 However, due to quirks in the mapping drivers (see #10417), the duplicated field was never reported to the `ClassMetadataFactory`, and due to a missing test case for the mis-configuration, this was never noticed.

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

admin closed this issue

2026-01-22 16:13:52 +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#12374