I have a code-first model where all entities are derived from a Entity base class. I have a property IsDeleted in base class which I want to ignore in all entities (I cannot remove/comment IsDeleted property since base class is used in many projects). Is there a way to configure modelBuilder to ignore this property form all entities (by conventions, I think), without to specify modelBuilder.Entity<...>().Ignore(l => l.IsDeleted) for all entities from my model?
Thanks,
Ion
You can do this using the new EF 6.1 Custom Code First Conventions:
modelBuilder.Types().Configure(c => c.Ignore("IsDeleted"));
This will ignore any property of the name IsDeleted in any of your types.
If you only want to do this for classes inheriting a certain base class, you can do:
modelBuilder.Types()
.Where(t => t.IsSubclassOf(typeof(MyBaseClass)))
.Configure(c => c.Ignore("IsDeleted"));
You can use the [NotMapped] annotation on the properties, but that will still need to be added for each entity which isn't the same as only specifying it once and having a convention for ignoring it.
Related
Using EF Core I can tell the modelBuilder to save properties having of enum type as string:
modelBuilder
.Entity<MyEntity>()
.Property(e => e.SomeEnumProperty)
.HasConversion<string>();
This has been asked and answered several times and is also described in the official docs.
However, the list of entitiy types (modelBuilder.Model.GetEntityTypes()) and their subtypes used in my project is rather lengthy and I image it to be error prone to loop over all managed entities, get their properties and their children properties recursivly via reflection and kind of semi-manually add the string conversion.
Is there a builtin way to automatically save all enum property values as strings using the StringEnumConverter?
Currently (EF Core 3.1.7) there is no other way than the one described in EF CORE 2.1 HasConversion on all properties of type datetime.
The difference here is the way of identifying Enum type properties, and due to the lack of easy public way of getting entity type builder (this property builder), the direct usage of SetProviderClrType metadata API instead of more intuitive HasConversion:
foreach (var entityType in modelBuilder.Model.GetEntityTypes())
{
foreach (var property in entityType.GetProperties())
{
var propertyType = Nullable.GetUnderlyingType(property.ClrType) ?? property.ClrType;
if (propertyType.IsEnum)
property.SetProviderClrType(typeof(string));
}
}
This must be at the end of your OnModelCreating override, or more specifically, after all entity types have been discovered.
I'm trying to migrate my old app to the new EF Core but I cannot find some relationships like:
HasRequired(o => o.Document).WithOptional(o => o.CancelNote);
Is there some extension methods? I cannot find on the docs.
The HasRequired I think that is possible to substitute with HasOne() method, but how about the WithOptional()?
Other thing, according to the docs the entity not uses the virtual keyword to create the navigation properties, how lazy load will work?
You will not find an HasOptional equivalent method in EF7. By convention if your FK property is nullable, you navigation property will be treated as optional
modelBuilder.Entity<Blog>()
.HasOne(p => p.Document)
.WithOne(i => i.CancelNote)
.HasForeignKey<Document>(b => b.CancelNoteForeignKey);
About your second question,EF Core (EF7) doesn't support Lazy Loading. In this link you will find the options you have now to load related entities
I really want to be able to use NodaTime in my Entity Framework Code First database projects but haven't found a "clean" way to do it. What I really want to do is this:
public class Photoshoot
{
public Guid PhotoshootId{get; set;}
public LocalDate ShootDate{get; set;} //ef ignores this property
}
Is there any supported or recommended approach to using NodaTime with EF Code First?
Until custom primitive type persistence is natively supported in Entity Framework, a common work around is to use buddy properties.
For each custom primitive within your domain model, you create an associated mapped primitive to hold the value in a format supported by Entity Framework. The custom primitive properties are then calculated from the value of their corresponding buddy property.
For example:
public class Photoshoot
{
// mapped
public Guid PhotoshootId{get; set;}
// mapped buddy property to ShootDate
public DateTime ShootDateValue { get; set; }
// non-mapped domain properties
public LocalDate ShootDate
{
get { // calculate from buddy property }
set { // set the buddy property }
}
}
We use NodaTime in our code first POCO's using exactly this approach.
Obviously this leaves you with a single type acting as both a code first POCO and a domain type. This can be improved at the expense of complexity by separating out the different responsibilities into two types and mapping between them. A half-way alternative is to push the domain properties into a subtype and make all mapped buddy properties protected. With a certain amount of wanging Entity Framework can be made to map to protected properties.
This rather splendid blog post evaluates Entity Framework support for various domain modelling constructs including encapsulated primitives. This is where I initially found the concept of buddy properties when setting up our POCO's:
http://lostechies.com/jimmybogard/2014/04/29/domain-modeling-with-entity-framework-scorecard/
A further blog post in that series discusses mapping to protected properties: http://lostechies.com/jimmybogard/2014/05/09/missing-ef-feature-workarounds-encapsulated-collections/
EF Core 2.1 has a new feature Value Conversions, which is exactly for this scenario.
//OnModelCreating
builder.Entity<MyEntity>
.Property(e => e.SomeInstant)
.HasConversion(v => v.ToDateTimeOffset(), v => Instant.FromDateTimeOffset(v));
.HasConversion has some other overloads to make this logic re-useable, for example you can define your own ValueConverter.
No "clean" way that I'm aware of because EF, as of this writing, doesn't have a mechanism for simple type conversion like you see in NHibernate (IUserType). A real limitation in EF as an ORM which causes me to change my domain to suit my ORM.
There is a provider specific way that works with Postgres (Npgsql).
Install the library
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL.NodaTime
And then while configuring DbContext, use this,
services.AddDbContext<PhotoshootDbContext>(opt =>opt.UseNpgsql(Configuration.GetConnectionString("ConnectionString"), o => o.UseNodaTime()));
There are some third party libraries for other providers too.
I've decided to use fluent mapping in Entity Framework. My intention was to map everyting by code without any atributes and auto mapping functions. Best way I've found is class EntityTypeConfiguration, that I implement for each entity in my project.
Later I add property to one of my entity. This property isn't needed to be persisted. I've expected, that until I add mapping for this property, it will be ignored by database and persistence layer. Unfortunatly it doesn't work that way, and property is mapped. Only way is to use Ignore method or NotMapped attribute, but I don't want to do it explicitly.
Is there any way, to stop Entity Framework from automapping? I've tried to remove all Conventions from DbModelBuilder, but it doesn't help.
So far as I am aware, there is no other way around it. You need to use either Ignore() or [NotMapped]. I tend to prefer the former as it does not clutter up the model.
Actually I have tried a lot of ways:
- custom convention to remove mapped properties
- removing all conventions
But the easiest (and cleanest) way was to use reflection inside the mapping class and to disable all property mappings that weren't configured.
The code for that (and also an usage example) is inside my public gist.
https://gist.github.com/hidegh/36d92380c720804dee043fde8a863ecb
I have a subclass in a different assembly to its base class. The parent is a POCO class used for EF Code First.
When I try to add an instance of inherited class to the database I get InvalidOperationException: "Object mapping could not be found for Type with identity 'Foo.Bar.MyInheritedClass'".
It works fine if subclass is in same assembly as base class.
In regular EF the solution seems to be a call to ObjectContext.MetadataWorkspace.LoadFromAssembly(assembly). But I can't figure out how this relates to Code First.
Any advice?
I'm using Entity Framework 4.1 RC.
I solved this by inheriting from the first assembliy's DbContext, adding a DbSet<> for the derived class, and then adding new instances of derived type to to that.
Posted code on MSDN forum here.
I know this post is a bit old, but I was able to accomplish this using #Dave's recomendation inside the constructor:
public Context() {
((IObjectContextAdapter)this).ObjectContext.MetadataWorkspace.LoadFromAssembly(
System.Reflection.Assembly.GetAssembly(
typeof(--[Inherited DbContext]--)));
}
I'm quite new to EF (Entity Framework 4) and I got the same exception when I made changes in the model.
My problem turned out to be that I did not know EF need all the names on all the navigation properties to agree, not only their type. For example if there is a navigation property named foo, then there needs to be a declared variable in the corresponding class with the very same name.