实体框架代码首字母PK / FK关系敏感性

问题描述

我有一个相当简单的复合一对多关系使用POCO / Fluent API定义，其中一列是一个字符串。

我发现我们的数据库这一列中的数据在abb，ABB方面是不一致的 - 这是我们的主要ERP系统由主要是我们无法控制的各种来源所饲养。

这是导致在加入相关表时首先使用EF代码的问题，因为当PK / FK的情况不同时，即使SQL Profiler显示执行正确的SQL并返回结果。

我正在使用WCF，因此有延迟加载和代理创建关闭，并且渴望加载需要使用Include的相关实体。例如

  var member = context.Member.Include（m => m.Audits）.First（m => m.Id == id）; 
  

在修改数据库模式之外是否有任何解决方案？

解决方案

EF不敏感连接比较

我有同样的问题，但是使用生成的模型）

原因是EF对关键字段进行区分大小写的比较，并且没有找到相关对象。 p>

我猜这个问题在于EDM关系管理器，也许有可能覆盖这种行为。

我发现了一个简单的解决方法：下面的相关属性：

  [EdmScalarPropertyAttribute（EntityKeyProperty = true，IsNullable = false ）] 
 [DataMemberAttribute（）] 
 public global :: System.String id 
 {
 get 
 {
 return _id.ToLower（）; // **<  -  here ** 
} 
 set 
 {
 if（_id！= value）
 {
 OnidChanging（value）; 
 ReportPropertyChanging（id）; 
 _id = StructuralObject.SetValidValue（value，false）; 
 ReportPropertyChanged（id）; 
 OnidChanged（）; 
} 
} 
} 
 private global :: System.String _id; 
 partial void OnidChanging（global :: System.String value）; 
 partial void OnidChanged（）; 
  

它实际上有效，但当然这是一个跛脚的工作。
我坚持一段时间，我（或某人）出来了一个更好的解决方案。

祝你好运！

I have a fairly simple composite one to many relationship defined using POCO/Fluent API, one column of which is a string.

I've discovered that the data in this column in our database is inconsistent in terms of case ie 'abb', 'ABB' - this is our main ERP system and is fed by a variety of sources which are mainly beyond our control.

This is leading to problems using EF code first when joining to related tables as the join is silently ignored by EF when the case of PK/FK is different even though SQL Profiler shows the correct SQL being executed and results returned.

I'm using WCF so have lazy loading and proxy creation turned off and am eager loading required related entities using Include. eg.

var member = context.Member.Include(m => m.Audits).First(m => m.Id == id);

Are there any solutions to this outside of amending the database schema?

解决方案

EF Insensitive join comparison

Hi I'm having the same problem (although not wit code first, but with a generated model)

The cause is that EF makes a case-sensitive comparison of the key fields, and it doesn'n find the related objects.

I'm guessing the problem lies in the "EDM Relationship Manager" and maybe there's a possibility of overriding this behavior.

I found a simple workaround for this: lower casing the related properties:

    [EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]
    [DataMemberAttribute()]
    public global::System.String id
    {
        get
        {
            return _id.ToLower(); // **<- here**
        }
        set
        {
            if (_id != value)
            {
                OnidChanging(value);
                ReportPropertyChanging("id");
                _id = StructuralObject.SetValidValue(value, false);
                ReportPropertyChanged("id");
                OnidChanged();
            }
        }
    }
    private global::System.String _id;
    partial void OnidChanging(global::System.String value);
    partial void OnidChanged();

It actually works, but, of course, it's a lame workoround.I'm sticking to it for a while util I (or somebody) comes out with a better solution.

Good Luck!

这篇关于实体框架代码首字母PK / FK关系敏感性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！