mirror of
https://github.com/doctrine/orm.git
synced 2026-03-24 06:52:09 +01:00
MappingException line 420 after v3.5.3 update #7567
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @davidnectarestudio on GitHub (Oct 28, 2025).
Bug Report
Summary
After
v3.5.3update I'm getting this error message:Duplicate definition of column 'id' on entity 'App\Main\Domain\Model\AirCompany\AirCompanyAttachment' in a field or discriminator column mapping.Current behavior
After Symfony clear cache command.
Expected behavior
No exception thrown.
How to reproduce
@davidnectarestudio commented on GitHub (Oct 28, 2025):
Full exception stack trace here:
@stof commented on GitHub (Oct 28, 2025):
Does it work fine if you define
AbstractBaseas aMappedSuperclass?Maybe having inherited mapped properties coming from classes that are not mapped by Doctrine does not work well with entity inheritance.
the expected usage of Doctrine is that mapped properties should be declared in mapped classes (either entities or mapped super-classes)
@davidnectarestudio commented on GitHub (Oct 29, 2025):
still failing even with
var/cache/*hard remove@davidnectarestudio commented on GitHub (Oct 29, 2025):
I doesn't change my source code since previous
v3.5.2and was working fine@mpdude commented on GitHub (Oct 30, 2025):
Maybe it was #12212?
AbstractBasemust be a MappedSuperclass either way@davidnectarestudio commented on GitHub (Oct 30, 2025):
@mpdude thanks for your hint, but even with or without
MappedSuperclassstill failing:@mpdude commented on GitHub (Oct 30, 2025):
#11404, #11488 report similar errors
@davidnectarestudio commented on GitHub (Nov 5, 2025):
@mpdude I've copied this code into
Doctrine\ORM\Mapping\Driver\ReflectionBasedDriveragain after v3.5.3 update, and all is working as usually@mpdude commented on GitHub (Nov 5, 2025):
That does not make the code more correct 🫠
There must be a mapping misconfiguration somewhere in your code, where you have mapping attributes in a class that is neither an entity nor a mapped superclass.
@davidnectarestudio commented on GitHub (Nov 6, 2025):
@mpdude where is the right place to put the
MappedSuperClassattribute? IntoAbstractBaseorAbstractAttachment? Keep in mind that both are abstract classes...@mpdude commented on GitHub (Nov 11, 2025):
AbstractBaseI note all your classes come from different namespaces. Also that’s a pattern I’ve seen in other bug reports before.
@davidnectarestudio commented on GitHub (Nov 12, 2025):
Yes, indeed I've 3 different entity managers as well, and this is the reason becuase I want to keep an
AbstractBaseinto a shared namespace. Maybe the problem is related with this kind of config? I need to acces 3 different databases located in same server:@davidnectarestudio commented on GitHub (Dec 18, 2025):
solved
@mpdude commented on GitHub (Dec 18, 2025):
And the reason was...?
Share your learning experience :)
@davidnectarestudio commented on GitHub (Dec 19, 2025):
Well, the main problem seems that
#[ORM\MappedSuperclass]must be applied into an abstract class located under same namespace root.We've solved just moving our
AbstractBasefromApp\Shared\Domain\ModeltoApp\Main\Domain\Model(where lives the class that implementsORM\InheritanceType)Before v3.5.3 no error thrown, but I'm not 100% sure that was fully working too, because I've discovered that the discriminator column
typewas empty.Now we are updated to the latest version and the
typecolumn is filled according to the extended class.@stof commented on GitHub (Dec 19, 2025):
this is not true. It must be applied in a class located in a namespace registered in the mapping configuration of the entity manager. But it can be a different namespace than the entity.
@davidnectarestudio commented on GitHub (Dec 19, 2025):
Ok, now I can see the real problem, thx @stof
The initial abstract class was located inside a namespace that was not registered.
@mpdude commented on GitHub (Dec 19, 2025):
😅 Good to hear that.
I was afraid that there might be in fact a bigger issue for a future me, given the other two similar-looking reports #11404 and #11488, plus I have an internal issue pending investigation where a co-worker made similar claims.
@pounard commented on GitHub (Jan 21, 2026):
Yes, exactly what I found out as well! See https://github.com/doctrine/orm/issues/11404#issuecomment-3773456042
This behavior was changed between 2.x and 3.x, because in 2.x it was working nicely, the MappingDriver didn't care where the parent class was located and was processing it using the child class driver configuration.