简体   繁体   English

多个添加的实体可能在数据库种子上具有相同的主键

[英]multiple added entities may have the same primary key on database seed

assuming I have the following model structures for an asp.net mvc 5 app using entity framework 6 假设我使用实体框架6为asp.net mvc 5应用程序提供了以下模型结构

class Athlete {
 int AthleteID {get; set;}
 List<YearsAsAthlete> YearsAsAthlete {get;set;}
}

class YearsAsAthlete {
 int YearsAsAthleteID {get;set;}
 int AthleteID {get;set;}
 [ForeignKey("AthleteID")]
 Athlete Athlete {get;set;}
 List<ContractRevenue> ContractRevenue {get;set;}
 List<AdvertisementRevenue> AdvertisementRevenue {get;set;}
}

class ContractRevenue {
 int ContractRevenueID {get;set;}
 int YearsAsAthleteID {get;set;}
 [ForeignKey("YearsAsAthleteID")]
 YearsAsAthlete YearsAsAthlete {get;set;}

 List<RevenueAmounts> RevenueAmounts {get;set;}
}

class AdvertisementRevenue {get;set;}
 int AdvertisementRevenueID {get;set;}
 int YearsAsAthleteID {get;set;}
 [ForeignKey("YearsAsAthleteID")]
 YearsAsAthlete YearsAsAthlete {get;set;}

 List<RevenueAmounts> RevenueAmounts {get;set;}
}

class RevenueAmounts {
 int RevenueAmountsID {get;set;}
 int AmountPaid {get;set;}
 date DateOfPayment {get;set;}
}

These models work fine when I have them like this, they have relationships and everything is delicious like a hot fudge sundae. 当我这样的时候,这些模型工作得很好,他们有关系,一切都很美味,就像一个热巧克力圣代。 When I run this, the database creates these tables and the RevenueAmounts table get 2 auto-generated foreign key columns for ContracRevenue and AdvertisementRevenue. 当我运行它时,数据库创建这些表,RevenueAmounts表为ContracRevenue和AdvertisementRevenue获取2个自动生成的外键列。

However, I don't want these as they're named strangely (ContractRevenue_ContractRevenueID) and I need some way to access the foreginkey id property in my post controller method for adding new values that correlate with the right type of revenue. 但是,我不想要这些,因为它们的命名奇怪(ContractRevenue_ContractRevenueID),我需要一些方法来访问我的post控制器方法中的foreginkey id属性,以添加与正确的收入类型相关的新值。

When I change the RevenueAmounts model to the following: 当我将RevenueAmounts模型更改为以下内容时:

class RevenueAmounts {
 int RevenueAmountsID {get;set;}
 int AmountPaid {get;set;}
 date DateOfPayment {get;set;}

 // ***NOTE adding foreign keys here

 int ContractRevenueID {get;set;}
 [ForeginKey("ContractRevenueID")]
 ContractRevenue ContractRevenue {get;set;}

 int AdvertisementRevenueID {get;set;}
 [ForeignKey("AdvertisementRevenueID")]
 AdvertisementRevenue AdvertisementRevenue {get;set;}
}

I start getting an exception: 我开始得到一个例外:

[SqlException (0x80131904): Introducing FOREIGN KEY constraint 'FK_dbo.AdvertisementRevenue_dbo.YearsAsAthlete_YearsAsAthleteID' on table 'AdvertisementRevenue' may cause cycles or multiple cascade paths. [SqlException(0x80131904):在表'AdvertisementRevenue'上引入FOREIGN KEY约束'FK_dbo.AdvertisementRevenue_dbo.YearsAsAthlete_YearsAsAthleteID'可能会导致循环或多个级联路径。 Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints. 指定ON DELETE NO ACTION或ON UPDATE NO ACTION,或修改其他FOREIGN KEY约束。

** EDIT ** ** 编辑 **

I've turned off the cascading delete functionality using the fluent API however now I'm getting a different exception: 我已经使用流畅的API关闭了级联删除功能但是现在我得到了一个不同的例外:

Unable to determine the principal end of the 'GIP.DAL.ContractRevenue_RevenueAmounts' relationship. 无法确定'GIP.DAL.ContractRevenue_RevenueAmounts'关系的主要结尾。 Multiple added entities may have the same primary key. 多个添加的实体可以具有相同的主键。

By the way, the exception is being thrown when I'm trying to seed a bunch of info into the database and then doing context.SaveChanges() at the bottom (only doing it once at the end) 顺便说一句,当我试图将一堆信息播种到数据库中然后在底部执行context.SaveChanges()时(仅在结束时执行一次context.SaveChanges() ,抛出异常

In your edit, you mention the 'Multiple added entities may have the same primary key.' 在您的编辑中,您提到“多个添加的实体可能具有相同的主键”。 error. 错误。 Without knowing all of the details of what you are doing here, it sounds like you are creating a relationship with an entity - of which there are two in the context with the same ID. 在不知道你在这里做什么的所有细节的情况下,听起来你正在创建一个与实体的关系 - 在上下文中有两个具有相同ID的实体。 These are probably new entities which have not yet been saved which is where they get an automatically generated ID from the database. 这些可能是尚未保存的新实体,它们从数据库中获取自动生成的ID。 If the relationship is based on the ID then there is some ambiguity because Entity Framework is unable to determine which of the new entities the relationship is actually pointing to - they both have the ID that the relationship is pointing to. 如果关系基于ID,则存在一些歧义,因为实体框架无法确定关系实际指向哪个新实体 - 它们都具有关系所指向的ID。

There are two potential fixes. 有两种可能的修复方法。

  1. Generate a temporary, unique identifier for entities as they are created in the context. 为实体在上下文中创建时生成临时唯一标识符。 Entity Framework will discard this as the entity is saved but up until that point, it can use it to tell one new entity apart from the other. 当实体被保存时,实体框架将丢弃它,但直到那时,它可以使用它来告诉一个新实体与另一个实体不同。 I have used negative integers for this purpose in the past. 我过去曾为此目的使用过负整数。

  2. Do not create the relationships using IDs but rather on entity references. 不要使用ID创建关系,而是使用实体引用创建关系。 If Entity Framework has a direct reference to the entity, then it does not need to go through the process of identifying the entity based on non-unique identifiers and should not have this problem. 如果实体框架具有对实体的直接引用,则它不需要经历基于非唯一标识符来标识实体的过程,并且不应该具有该问题。

This is happening because Entity Framework cannot determine which object within the relationship is the parent when Cascade delete is enabled. 发生这种情况是因为在启用Cascade删除时,Entity Framework无法确定关系中的哪个对象是父对象。

Are you using Code First? 你在使用Code First吗? When the Migration is generated you will see an option for cascade delete in the table declaration. 生成迁移后,您将在表声明中看到级联删除选项。 This should be resolved if you set that to false. 如果将其设置为false,则应解决此问题。

However the bigger issue is that you are creating object relationships that doesn't implement an Aggregate Root which most often would avoid this issue. 但是,更大的问题是您正在创建不实现聚合根的对象关系,这通常会避免此问题。

I had the same problem but in my case there was another solution. 我有同样的问题但在我的情况下有另一种解决方案。 In a loop i was adding parents for each parent I was adding children. 在一个循环中,我为每个父母添加了父母,我正在添加孩子。 There is relation between parent and child. 父母和孩子之间有关系。 Of course I used the FK as a virtual reference column but still the problem appeared. 当然我使用FK作为虚拟参考列,但问题仍然存在。

foreach (var parent in parents)
{
   var id = parent.Id;
   var parentEntity = new Parent();
   this.Context.Set<Parent>().Add(parentEntity);
   parentEntity.CreatedOn = DateTime.UtcNow;
   ...

   foreach (var child in parents[id].Children)
   {
       var childEntity = new Child();
       //this.Context.Set<Child>().Add(childEntity);
       parent.Children.Add(childEntity);
       childEntity.CreatedOn = DateTime.UtcNow;
       ...
   }
}

I had to comment out the line that was adding the child entity to EF context and it fixed the issue. 我必须注释掉将子实体添加到EF上下文的行,并修复了问题。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

相关问题 多个添加的实体可能具有相同的主键 - Multiple added entities may have the same primary key EF6:多个添加的实体可能具有相同的主键 - EF6: Multiple added entities may have the same primary key 多个添加的实体可能在实体框架中具有相同的主键 - Multiple added entities may have the same primary key in Entity Framework 无法确定 X 关系的主端。 多个添加的实体可能具有相同的主键 - Unable to determine the principal end of the X relationship. Multiple added entities may have the same primary key 对于某些循环实体,多个添加的实体可能具有相同的主键 - multiple added entities may have the same primary key for some cyclic entity 实体框架6.1:添加的多个实体可能具有相同的主键 - Entity Framework 6.1: Multiple added entities may have the same primary key 无法确定关系的主要终点,多个添加的实体可能具有相同的主键 - Unable to determine the principal end of the relationship, Multiple added entities may have the same primary key EF 6.多个添加的实体可能具有相同的主键。 错误 - EF 6. Multiple added entities may have the same primary key. Error 无法确定etaxiDataModel关系的主要结尾。 多个添加的实体可以具有相同的主键 - Unable to determine the principal end of the etaxiDataModel relationship. Multiple added entities may have the same primary key 无法确定“ Vehicle_VehicleClass”关系的主要结尾。 多个添加的实体可能具有相同的主键 - Unable to determine the principal end of the 'Vehicle_VehicleClass' relationship. Multiple added entities may have the same primary key
 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM