Entity Framework Core 仍然选择旧专栏 [英] Entity Framework Core still picks up old column

问题描述

我最近从我的表中删除了一列 ConversationId.当我开始调试我的服务并尝试保存时，我收到一个错误:

I recently delete a column ConversationId from my tables. When I start to debug my service and try to save I am getting an error:

无效的列名ConversationId".

Invalid column name 'ConversationId'.

代码:

public class AstootContext : DbContext
{
    public AstootContext(DbContextOptions<AstootContext> options)
        : base(options)
    { }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
    }

    public DbSet<ServiceRequest> ServiceRequests { get; set; }
}

我的实体看起来像这样:

And my entity looks like this:

public class ServiceRequest
{
    public int Id { get; set; }
    public int SenderUserId { get; set; }
    public int PriceTypeId { get; set; }
    public decimal Price { get; set; }
    public bool IsAccepted { get; set; }
    public DateTime Created { get; set; }
    public int MessageId { get; set; }
}

从代码中删除了对 ConversationId 的所有引用，我已经重建，但我仍然收到此错误，我不明白为什么.

All references to ConversationId were removed from the code, I've rebuilt, yet I'm still getting this error and I don't understand why.

这是我的 SQL Server 表，因为您可以看到没有 ConversationId:

This is my SQL Server table as you can see there is no ConversationId:

是否有我需要删除的秘密缓存或者我必须运行什么来更新它?

Is there a secret cache that I need to delete or something I have to run to update this?

推荐答案

EF Core 是基于代码的 ORM，这里最重要的是 M - Mapper.实际的数据库结构是什么并不重要，重要的是 EF *认为**它基于您的代码模型(实体类及其属性，结合数据注释、流畅的配置和一组约定).

EF Core is code based ORM, with the most important here being the M - Mapper. It doesn't matter what the actual database structure is, the important is what EF *thinks** it is based on your code model (entity classes and their properties, combined with data annotations, fluent configuration and set of conventions).

所以问题应该出在代码上.由于您删除了 explicit 属性，它应该是由 阴影属性.正如文档链接中所解释的那样，shadow 属性通常是按惯例从关系中引入的:

So the problem should originate from code. Since you've removed the explicit property, it should be caused by shadow property. And as explained in the documentation link, shadow properties are usually introduced by convention from relationships:

当发现关系但在依赖实体类中找不到外键属性时，可以按照约定创建阴影属性.在这种情况下，将引入影子外键属性.

Shadow properties can be created by convention when a relationship is discovered but no foreign key property is found in the dependent entity class. In this case, a shadow foreign key property will be introduced.

文档还解释了在不同场景中应用的命名规则.

The documentation also explains the naming rules applied in different scenarios.

一个名为ConversationId的影子属性可以通过多种方式引入，但根据提供的信息，最可能的原因是有一个名为Conversation的实体类定义通过具有集合类型导航属性与 ServiceRequest 的一对多关系:

A shadow property called ConversationId can be introduced in a several ways, but according to the provided information, the most likely cause is to have an entity class called Conversation defining one-to-many relationship with ServiceRequest by having a collection type navigation property:

public class Conversation
{
    public int Id { get; set; }
    // ...
    public ICollection<ServiceRequest> ServiceRequests { get; set; }
}

根据您的评论确实如此.

Which according to your comment was indeed the case.

为完整起见，以下是生成此类属性的其他一些可能场景:

For completeness, here are some other possible scenarios generating such property:

(1) Conversation中没有集合导航属性，ServiceRequest中引用导航属性:

(1) No collection navigation property in Conversation, reference navigation property in ServiceRequest:

public class Conversation
{
    public int Id { get; set; }
    // ...
}

public class ServiceRequest
{
    // ...
    public Conversation Conversation { get; set; }
}

(2)Conversation和ServiceRequest中没有导航属性，流畅的配置:

(2) No navigation properties in Conversation and ServiceRequest, fluent configuration:

modelBuilder.Entity<Conversation>()
    .HasMany<ServiceRequest>();

或

modelBuilder.Entity<ServiceRequest>()
    .HasOne<Conversation>();

或以上的变体.

(3) 不涉及关系，通过fluent配置创建shadow属性:

(3) No relationship involved, shadow property created through fluent configuration:

modelBuilder.Entity<ServiceRequest>()
    .Property<int>("ConversationId");

这篇关于Entity Framework Core 仍然选择旧专栏的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！