Open d-ziegler opened 2 years ago
Was hoping that its maybe working with 7.0.0-alpha.1.22054.3 as there were some changes in the RelationshipDiscoveryConvention. Sadly its not. Do you plan to fix this before EF 7?
I am facing exactly the same issue after upgrading to EF Core 6 from EF Core 5, all the [NotMapped] attributes are ignored. It would be nice to know if a fix can be expected before EF7 indeed.
In 6.0 we had to change relationship discovery logic to enhance support for shared-type entity types, which introduced this issue where some [NotMapped]
attributes are not being applied. Fixing this has a high chance of breaking something else, so it doesn't meet the patch bar.
In 7.0 we'll work on https://github.com/dotnet/efcore/issues/15898 which will allow us to use reference counting for entity types - a more accurate method to determine whether an entity type should be part of the model.
You can call EntityTypeBuilder.Ignore
for now.
This issue caught me cold handed now, too. After upgrading to .net 6, a [NotMapped] attr. was ignored, leading to model build failure. This is a major blocker for us, as we rely on many NotMapped columns that are not to be mapped, obviously (and it doesn't give me confidence in using this version if I cannot rely on the annotations being taken into account!)
Waiting for 7.0 is not a real solution, either. So is a fix in 6 not planned at all?
@Phloog The workaround is to use EntityTypeBuilder.Ignore
.
@ajcvickers I'm trying to find all occurrences (without too much trial&error) where [NotMapped] may be ignored and what Entity-Properties I need to explicitly ignore using EntityTypeBuilder.Ingore. Am I assuming correctly that only non-primitive Properties with getter and setter are affected? Because EF for example tries to map an Entity type of Dictionary<string,string> when such a property exists in some Entity-Classes. (unfortunately, the exception doesn't contain - or I wasnt able to find - a hint which enclosing entity type was the culprit, only the type Dictionary<string,string> itself is mentioned).
is there a better way to find the relevant properties?
Thanks, regards
@Phloog You should be able to find all properties that currently have [NotMapped]
on them and add an Ignore
call for each of these. This might result in more calls to Ignore
than are strictly necessary, but it ensures you won't miss any.
@ajcvickers thanks, but for at least one of the props, this didn't seem to do the trick; I needed to remove the setter of said Dictionary<string,string>-Property and replace it by an explicit SetXXX-method, otherwise the modelbuilder insisted on trying to map the "Entity type" Dictionary<string,string> :-(
@Phloog That sounds like a different bug. Please open a new issue and attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate.
if you are using the workaround: modelBuilder.Entity
I've encountered a strange problem after upgrading to EF core 6 from EF core 5 with entity types added to the modelBuilder.Model which are annotated with the NotMapped attribute.
EF Core version: 6.0.0 (offical) + 6.0.0-rtm.21519.8 (daily) Database provider: Microsoft.EntityFrameworkCore.SqlServer Target framework: .NET 6.0 Visual Studio 2022 17.0.0
Example project Ef-Test.zip
This happens e.g. after an add-migration via the package manager console. I have added Debugger.Launch + .Break in the MyDbContext for debugging.
The problem here is, that I've three entities in MyDbContext (ImportPerformance, ScreenContentCountry and TrackPerformanceView) and another entity (not included in 'MyDbContext' (Auditorium)) which is referenced by the TrackPerformanceView with the NotMapped attribute.
Even though the NotMapped attribute is set, the created modelBuilder.Model contains the EntityType 'Auditorium'. This doesn't happen after downgrading to EF Core 5.X.
In one of our projects with multiple datacontexts this leads to an exception on building a datacontext model.
Couldn't reproduce this easily in the example project, but I guess the error with this relies on the fact that the NotMapped property entitytypes (which are in another datacontext) get added to the model of the wrong datacontext without defining the relation via the fluent api in OnModelCreating.
To get back to the example project:
MyDbContext
DataContext Entities: ImportPerformance
ScreenContentCountry
TrackPerformanceView
Auditorium (not added in the DbContext, only referenced with NotMapped attribute)
As you might have seen in the comments of the code, there are ways to get the Auditorium entity type being ignored properly e.g. adding a navigation property for TrackPerformanceView in the ScreenContentCountry entity. Also not referencing the TrackPerformanceView from the ImportPerformance leads to a correct model with the Auditorium entity type being ignored.
In the example project the migration will anyway be generated correctly without the Auditorium type being added to the migration code.
What I've found out so far debugging ef core is that the RelationshipDiscoveryConvention.IsCandidateNavigationProperty returns true for the NotMapped Auditorium property in TrackPerformanceView
this happens because sourceEntityTypeBuilder.IsIgnored(navigationName) returns false in this case.
RelationshipDiscoveryConvention.IsCandidateNavigationProperty
(After doing one of the steps said above this leads to the SharedAuditorium property being ignored properly, returning here false and for IsIgnored true).
Digging some deeper here leads to the TypeBase.FindDeclaredIgnoredConfigurationSource which is being called but has an empty dictionary of _ignoredMembers in the bugged case.
Let me now if you need some more information.