Closed bradmarder closed 2 years ago
Based on info provided above, I could not reproduce this. The table is named Posts only. @bradmarder - Please provide a simple repro code which can demonstrate what you are seeing.
I just updated an rather large app to asp.net core 2 / ef core2 and got the same error when using OpenIddict, which worked fine on net core 1.1, and according to the author
the code that registers the OpenIddict models in the model builder hasn't changed between OpenIddict 1.0 and 2.0 (and yet it works fine with OpenIddict 1.0 + EF Core 1.0).
Here is a minimum project : https://github.com/MoxxNull/efcore2test where I copied a minimum of the code from OpenIddict to reproduce the error.
Comment out
options.UseSampleExtension();
and the query is against the correct "SampleEntities" Table.
With .UseSampleExtension() it's againt "SampleEntity" and produces an error.
Steps I've done:
Same thing here...
Actually the workaround right now is to use the ToTable("PluralTableName")
from EntityTypeBuilder
which was not needed in the previous version...
Note for triage: In the repro provided the code is using an external IModelCustomizer, which means the default customizer that does the naming is not getting used.
@bradmarder @MoxxNull @pavlospap As a workaround, can you try deriving your customizer from RelationalModelCustomizer? Calling the base.Customize method should then set the table names appropriately.
Long term, we probably either need to do #9330 or something else that will allow the default customizer to run even if an application one is also being used.
@bradmarder @MoxxNull @pavlospap As a workaround, can you try deriving your customizer from RelationalModelCustomizer? Calling the base.Customize method should then set the table names appropriately.
That indeed works, thanks. The only concern I have is that RelationalModelCustomizer
is one of those "pubternal" infrastructure classes that we're not supposed to directly use or inherit from. Are you fairly confident no breaking change will be added in EF Core 2.x?
@PinpointTownes RelationalModelCustomizer is a public class, not an "internal" one, so, unless something extreme happens, it won't be broken in 2.x.
@ajcvickers right, but for the 2.0 release, RelationalModelCustomizer
's summary was This API supports the Entity Framework Core infrastructure and is not intended to be used directly from your code. This API may change or be removed in future releases.
I saw this changed in a recent commit (https://github.com/aspnet/EntityFrameworkCore/commit/e5b6a773230238c1625196d0ea1970b350927363#diff-bc9d80d65a207b9792fa19c80c453799R14), but I thought it was worth double-checking it wouldn't change in the future :sweat_smile:
@PinpointTownes Yeah, the documentation for the relational assembly didn't get completed until after the 2.0 release. I didn't remember that it said that before--what it says now is correct, even for the 2.0 release.
Closing as a duplicate of #9330 since we decided in triage to address this issue by fixing that one.
Using the latest efcore 2 preview from myget, it seems EF under certain conditions is not using the name of the DbSet<> property name as the table name. This is not exactly a simplified example...but this is the gist.
In this case, I would expect the table generated to be called Posts... but instead it is using the singular version Post (the name of the entity). Unfortunately, I can't create the code to reproduce this exactly. This worked as expected in efcore 1.12. All I know is the following.
-There is no code inside the
OnModelCreating
override that explicitly sets the table name. -No entity has theTable
attribute. -AllDbSet
property names are explicitly pluralized.Further technical details
EF Core version: 2.0.0-rtm-26360 Database Provider: Microsoft.EntityFrameworkCore.SqlServer Operating system: win10 x64 IDE: (e.g. Visual Studio 2017 15.3.0 preview 4.0)