Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NavigationFixer.SetForeignKeyProperties doesn't set value as StoreGenerated #22603

Closed
AndriySvyryd opened this issue Sep 18, 2020 · 4 comments · Fixed by #25894
Closed

NavigationFixer.SetForeignKeyProperties doesn't set value as StoreGenerated #22603

AndriySvyryd opened this issue Sep 18, 2020 · 4 comments · Fixed by #25894
Labels
area-change-tracking closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@AndriySvyryd
Copy link
Member

It means that when inserting a principal entity with a store-generated key and a dependent in the same transaction and something fails after the principal was inserted the dependent might end up disconnected as it will retain the store-generated FK value that is no longer valid.

@ajcvickers
Copy link
Member

@AndriySvyryd Is this something you think we should fix for 5.0?

@AndriySvyryd
Copy link
Member Author

No, I don't think this is a regression.

@ajcvickers ajcvickers self-assigned this Sep 21, 2020
@ajcvickers ajcvickers added this to the Backlog milestone Sep 21, 2020
@ajcvickers ajcvickers modified the milestones: Backlog, 6.0.0 Nov 5, 2020
@ajcvickers ajcvickers added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label Sep 6, 2021
@stevendarby
Copy link
Contributor

@ajcvickers Cool, I think I spotted this recently doing some work on resiliency when saving changes. The example given above mentions an error occurring between inserts- can I just check that this also covers the case where saving succeeds but changes have not been accepted yet? Currently the dependent FK is set at this point even though the principal ID isn’t. Looking at the PR I am fairly sure it fixes this too but I wanted to check in case it’s a separate issue worth raising. Thanks!

@ajcvickers
Copy link
Member

@stevendarby Yes, that is the same issue. Should now be fixed so that the FK is set at the same time as the PK. It would be good to give it a try to make sure, or maybe even submit a test for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-change-tracking closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants