多重约束违规使用可选要求的EF代码优先+流利的关系？ [英] Multiplicity constraint violations with optional-required EF Code First + Fluent relationship?

问题描述

由于某种原因，我有我做了我的脑海而回上EF 6项目，我会尽量避免命名外键。我定义在模型的大部分不增量测试它，所以我一直运行到多重性和不完全流利的API定义问题：

一个从关系在User_InternalAuthAssociationSet在
已删除状态。由于多重约束，相应的
'User_InternalAuth_Target还必须在已删除状态。

在一个案例中，在这里是代码：

  nModelBuilder.Entity<使用者>（）
 .HasOptional< InternalAuth>（U => u.InternalAuth）
 .WithRequired（A => a.User）
 .WillCascadeOnDelete（真）; 
  

我的理解是，它是说：

• 实体用户


• 有一个可选的属性 InternalAuth 类型 InternalAuth


• 在另一端， InternalAuth 有一个必需的属性用户，这样的所有的 InternalAuth 活动的用户取值但用户 S可有也可能没有一个'InternalAuth。


• 如果在用户被删除，所以做他的 InternalAuth ，如果他有一个（这是否覆盖治疗自选像nullables的可选行为？）

然而，当我试图删除用户我收到了一个异常 InternalAuth 之间的一些关联的多重性和用户。

1. 这是真的，如果EF理解有关系的多重性，有一种方法为它所以有一个规范的命名约定，它提供一个唯一的列名？




2. 如果是这样，你真的需要通过注解模型或通过流畅API明确定义外键？




3. 如果不是，它是一个有价值的或者是不可取的事情，我应该继续努力，以避免呢？ （我一起迁移的数据模型，数据库管理，任何EF怪癖的线条思考）




4. 为什么试图删除的关系违反上述多重约束？还有什么它需要知道什么？

解决方案

假设

您可以通过使用WillCascadeOnDelete方法上配置的关系级联删除。如果依赖实体的外键不可为空，则代码第一次设置上关系的级联删除。如果对相关实体的外键可为空，代码第一次不设置上的关系级联删除，而当主被删除外键将被设置为null。

我的猜测是以下几点：在FK可为空这样的事实来设置它所需的约束为空导致异常的崛起

解决方案之一是将FK的PK，也就是添加，在InternalAuth的FK到用户的PK。这样做将标志着实体设置了PK为null的一部分时删除。

For some reason I had my made my mind a while back on an EF 6 project that I would try to avoid naming foreign keys. I defined much of the model without testing it incrementally and so I have been running into multiplicity and incomplete Fluent API definition issues:

A relationship from the 'User_InternalAuth' AssociationSet is in the 'Deleted' state. Given multiplicity constraints, a corresponding 'User_InternalAuth_Target' must also in the 'Deleted' state.

In one case, here is the code:

nModelBuilder.Entity<User>()
    .HasOptional<InternalAuth>(u => u.InternalAuth)
    .WithRequired(a => a.User)
    .WillCascadeOnDelete(true);

My understanding is that it is saying:

• The entity User
• Has an optional property InternalAuth of type InternalAuth
• On the other end, InternalAuth has a required property User, so that all InternalAuths have Users but Users may or may not have an `InternalAuth.
• If the User gets deleted, so does his InternalAuth if he has one (does this override an optional behavior of treating optionals like nullables?)

However when I try to delete a User I receive an exception about the multiplicity of some association between InternalAuth and User.

1. Is it true that if EF understands the multiplicity of a relationship there is a way for it to provide it a unique column name for it so there is a canonical naming convention?

2. If so, do you ever really need to define foreign keys explicitly by annotating the model or through Fluent API?

3. If not, is it a worthwhile or advisable thing that I should keep trying to avoid it? (I'm thinking along the lines of migrating the data model, database administration, any EF quirks)

4. Why does attempting to delete the relationship above violate a multiplicity constraint? What else does it need to know?

解决方案

assuming that

You can configure cascade delete on a relationship by using the WillCascadeOnDelete method. If a foreign key on the dependent entity is not nullable, then Code First sets cascade delete on the relationship. If a foreign key on the dependent entity is nullable, Code First does not set cascade delete on the relationship, and when the principal is deleted the foreign key will be set to null.

My guess is the following : the FK is nullable so the fact to set it to null with the required constraint causes the rise of the exception.

One solution is to put the FK in the PK, that is add, in InternalAuth, the FK to User in the PK. Doing this will mark the entity as deleted when setting a part of his PK to null.

这篇关于多重约束违规使用可选要求的EF代码优先+流利的关系？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！