-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
ForeignKeyAttribute on skip navigations fails to remove by-convention join table from model #27990
Comments
Probably a duplicate of #25797 |
@ajcvickers Do you think this was fixed by PR #29794? |
@bricelam Still throws with 8.0 preview 2 |
We were having a similar problem at work when setting up a unit test database, and we thought maybe it was related to this issue. However, in the process of diagnosing our error, we also figured out what's happening with the reproduction code. I know it's old, but it's still open, so I figured I would drop a quick comment. The reproduction code is configuring the relationships twice - once in |
…ference it Fixes #27990 The issue here was a skip navigation with a `ForeignKeyAttribute`. At first I thought that this was not valid, but it turns out we decided that this configuration specified the name of the FK property in the join table. However, this by-convention join type was then discarded and replaced with an explicitly configured join type. This normally removes the old join type from the model, but this doesn't happen here because the `ForeignKeyAttribute` resulted in the join type having a "data annotation" configuration source. This is not really correct; the FK attribute just says that the FK properties should have a given name, not anything about the type, so the entity type configuration source should not be changed here. This allows the by-convention join type to be removed like it should, and hence we don't have two join tables mapped that differ only by case.
…ference it Fixes #27990 The issue here was a skip navigation with a `ForeignKeyAttribute`. At first I thought that this was not valid, but it turns out we decided that this configuration specified the name of the FK property in the join table. However, this by-convention join type was then discarded and replaced with an explicitly configured join type. This normally removes the old join type from the model, but this doesn't happen here because the `ForeignKeyAttribute` resulted in the join type having a "data annotation" configuration source. This is not really correct; the FK attribute just says that the FK properties should have a given name, not anything about the type, so the entity type configuration source should not be changed here. This allows the by-convention join type to be removed like it should, and hence we don't have two join tables mapped that differ only by case.
@AndriySvyryd Happy for you to take this over; I almost gave up when I realized it had nothing to do with SQLite. :-D The tests, at least, should be helpful. |
With code created by dbScaffold (using global tool 6.0.4) in EF Core 6.0.4 I get the following error:
I think the error must exist for at least some time, but I can't tell exactly which version introduced it.
Here's a sample program creating that error: https://github.com/janschreier/EfCoreInMemoryBug
the dbContext code-is from a larger project and i tried to strip it down as much as possible while still receiving the same error. So it looks a bit akward.
OnModelCreating()
is also called twice which is unexpected to me but then I never had a breakpoint on it so I'm not sure if that's okay or notEF Core version: 6.0.4
Database provider: Microsoft.EntityFrameworkCore.Sqlite
Target framework: net6.0.4
Operating system: win 10x64
IDE: Visual Studio 2022 17.1.6
The text was updated successfully, but these errors were encountered: