mirror of
https://github.com/doctrine/orm.git
synced 2026-03-23 22:42:18 +01:00
DDC-3745: OneToOne identity through foreign entity exception on flush #4594
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 @doctrinebot on GitHub (May 22, 2015).
Originally assigned to: @lcobucci on GitHub.
Jira issue originally created by user Daveet:
Also asked at SO: https://stackoverflow.com/questions/30402203
I'm adding it here as well as an issue here, because I believe it just might be Doctrine's bug.
I have
UserandUserProfileOneToOne–related Doctrine ORM entities. They should always exist as a pair, there should be noUserwithoutUserProfile.User should get its id from autoincrement, while UserProfile should have User's id. So they both should have the same id and there is no other column to set up the relationship (Doctrine docs: Identity through foreign Entities).
User's id is both a primary key (PK) and foreign key (FK) at the same time.
I managed to set it up, but it requires that User is saved first and only later UserProfile is created and saved in a separate step.
What I want is that UserProfile is always created with User, in the constructor, but if I do that, I get this exception:
Doctrine\ORM\ORMInvalidArgumentException: The given entity of type 'AppBundle\Entity\UserProfile' (AppBundle\Entity\UserProfile@0000000052e1b1eb00000000409c6f2c) has no identity/no id values set. It cannot be added to the identity map.Please see code below – it works, but not the way I want. The php comments show what I want to achieve.
@petrjirasek commented on GitHub (Feb 16, 2016):
Hello,
I would like to ask you if is there any progress? I have the same problem.
Thank you.
@dm3ch commented on GitHub (Oct 5, 2016):
Hello, is there any progress with this bug? Is it fixed
@aaleksandrov commented on GitHub (Oct 25, 2016):
Same issue for me. It there any fix or workaround?
@scarbo87 commented on GitHub (Nov 1, 2016):
+1
@nico-incubiq commented on GitHub (Nov 9, 2016):
Same here.
@jorge07 commented on GitHub (Jan 27, 2017):
any fix or workaround?
@lcobucci commented on GitHub (Jan 27, 2017):
This was already fixed on #1570 when
$weightwas introduced onCommitOrderCalculator.I've ran the test bellow on
masterand it passes with no issues, so I'm closing this issue.On the PR we have the explanation why this wasn't backported on
v2.5.x.@igaponov commented on GitHub (May 22, 2017):
I have the same issue
@lcobucci Your test is wrong, I've checked it on the last version and UserProfile is not actually saved after flush, it's not passed to
UOW::scheduleForInsert()as well as toUOW::addToIdentityMap(), that's why there is no exception. But if you manually persist profile before flush you'll get this:Upd. the problem is in four asterisks in phpdoc for
$profileproperty, doctrine doesn't see that annotation and User has no relation:@lcobucci commented on GitHub (May 22, 2017):
@igaponov you're right about the docblock, now my test fails as well... and it actually fails on
persist()and notflush().IMO this is an edge-case since it only happens if
xxxxUser#idis a post insert generated id (auto increment or sequences). If strategy isNONEorUUIDit works just fine.@guilhermeblanco @Ocramius I'd say this is a
won't fixand we should actually document this, what do you think?@ste93cry commented on GitHub (Jan 9, 2018):
After updating to Doctrine 2.6 I get the same error while before it was working fine. I now have to use two
persistandflushcalls even though the main entity has thecascadeoption set topersist. Plus, I was relying on the fact that all INSERT queries were automatically executed in a transaction and that if any of the statements failed everything failed as well but now I have to wrap all entity operations inside atransactionalfunction call@ro0NL commented on GitHub (Jan 9, 2018):
Im also hitting the same issue. I've identified it for now with
int(1)as a value is generated anyway. WFM :) but totally unexpected yes.@timostamm commented on GitHub (Jan 10, 2018):
Just followed the doctrine docs on Identity through foreign Entities and stumbled upon this bug.
When I create a new Article using the entities declared in "Use-Case 1: Dynamic Attributes", I get the mentioned exception:
This was really unexpected.
@ro0NL thanks for the tip. Initializing the auto-generated id works:
Maybe this bug should be reopened? Or mentioned in the docs?
@robertonetresults commented on GitHub (Jan 16, 2018):
I have the same error too after updating to Doctrine 2.6. I can't apply the @ro0NL tip because I can't change the DB structure.
@NicolaF commented on GitHub (Jan 23, 2018):
For people having issues with 2.6, see #7003.