实体框架的地图数据错了，当标识列不唯一 [英] Entity Framework maps data wrong when the identity column is not unique

问题描述

没有进入为什么，才明白这一点继承和我有什么一起工作：）

Without getting into the "why", just understand this in inherited and what I have to work with :)

我有一个EF6 EDMX映射到一个视图。有上没有标识列，因此为了EF映射实体，先不要空列被选为PK。这背后的最初的想法是它的只读的任何更新或删除将被完成。没有过滤（ODATA坐落在此之上），而仅的 - 我的意思只是 - 这是使用的方法是选择最前N * 从实体。

I have an EF6 edmx mapped to a view. There is no identifying column on it, so in order for EF to map the entity, the first not-null column was selected as the PK. The original thought behind this was it is read only no updates or deletes would be done. There is no filtering (ODATA sits on top of this), and the only - and I mean only - way this is used is select top N * from the entity.

有4条在视图中。

TypeCode | Contact | UserID | LocaleID | EntityName
---------------------------------------------------------
1          6623      1032     9          Jane
1          6623      1032     9          Jane
1          6623      1032     9          John
1          6623      1032     9          John

我看到的问题是，EF被映射所有4行相同。以上所有的约翰的名字成为简

The problem I am seeing is that EF is mapping all 4 rows the same. All "John" names above become "Jane"

OK，抛开设计决策，并且对视图中没有识别记录的事实，为什么EF映射最后两行错了吗？我最初的想法是，既然PK设置为类型码它不知道该怎么做。但是，为什么会使用时，只需从数据库读取结果键列？我还以为它只是要紧的更新和删除

OK, putting aside the design decision, and the fact there is no identifying record on the view, why is EF mapping the last two rows wrong? My initial thought is that since the "PK" is set as TypeCode It doesn't know how to do it. But why would it be using the key column when just reading results from the database? I would have thought it only mattered for updates and deletes

推荐答案

如果您通过实体框架查询数据，默认行为是每个物化实体通过其唯一的密钥跟踪。独特的键由你告诉EF为重点使用，或者，它推断为主要属性（类型码你的情况）的任何属性。每当重复实体键试图进入变更跟踪，则会引发错误，告诉该对象已被跟踪。

If you query data by Entity Framework, the default behavior is that each materialized entity is tracked by its unique key. The unique key consists of any properties you told EF to use as key, or, alternatively, it inferred as key properties (TypeCode in your case). Whenever a duplicate entity key tries to enter the change tracker, an error is thrown telling that the object is already being tracked.

所以EF简单的不能的兑现有重复的主键值对象。这将损害其跟踪机制。

So EF simply can't materialize objects having duplicate primary key values. It would compromise its tracking mechanism.

看来，至少在EF6，的 AsNoTracking（） 能作为一个变通。 AsNoTracking 告诉EF只是兑现对象，而不跟踪他们，所以它不产生实体按键。

It appears that, at least in EF6, AsNoTracking() can be used as a work-around. AsNoTracking tells EF to just materialize objects without tracking them, so it doesn't generate entity keys.

我的不的明白的是为什么EF不抛出时，它读取重复的主键值异常。现在，它静静地返回相同的对象多次遇到的SQL查询结果它的键值。这已经引起了许多许多人感到困惑，没有尽头。

What I don't understand is why EF doesn't throw an exception whenever it reads duplicate primary key values. Now it silently returns the same object as many times as it encounters its key value in the SQL query result. This has caused many many people to get confused to no end.

顺便说一句，以避免此问题的常用方法是通过生成临时唯一键值到视图使用 ROW_NUMBER 在SQL Server中。这对你读一次到一个上下文实例只读数据足够好了。

By the way, a common way to avoid this issue is by generating temporary unique key values to the view by using ROW_NUMBER in Sql Server. That's good enough for read-only data that you read once into one context instance.

这篇关于实体框架的地图数据错了，当标识列不唯一的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！