Виртуальная собственность не будет лениво загружаться в Entity Framework 6 (с предупреждением)

Question

Я застрял...

Вот моя модель:

public class Payment 
{
    [ForeignKey("RecipientId")]
    public virtual Account Recipient { get; set; }

    public string RecipientId { get; set; } 

    [Key, Column(TypeName = "char"), MaxLength(36)]
    public string PaymentId { get; set; }
}

И эта модель представлена ​​через свободный API как следующее:

modelBuilder.Entity<Payment>()
    .HasRequired(t => t.Recipient)
    .WithMany()
    .HasForeignKey(t => t.RecipientId)
    .WillCascadeOnDelete(false);

Это работало в течение почти 3 лет. У нас никогда не было проблем с этим отображением.

Недавно мы решили поменятьMaxLength"приписать то, что вы видите выше. Это пошло от"8"до"36".

Наши предыдущие идентификаторы начали сталкиваться, и поэтому пришло время измениться.

Изменять все в коде было хорошо. Наши юнит-тесты все проходят. Когда мы запускаем наш проект локально, мы видим правильные результаты.

Толчок к производству был также довольно номинальным. Мы изменили нашу таблицу и перенастроили наш индекс, чтобы отразить длину нового типа столбца (из MaxLength(8) в MaxLength(36)).

Опять же... Это была та же самая процедура, которую мы выполняли на месте.

Здесь возникает проблема:

Объекты (Оплата), которые создаются и сохраняются с новым, более длинным "PaymentId"сделано-так без ошибок. Добавление отношений также, кажется, работает без ошибок.

Ошибка возникает, когда мы выполняем любой из API-интерфейсов запросов в структуре сущностей (Find, ToList, SingleOrDefault и т. Д.).

Наша ленивая загрузка не работает. Получатели нулевые! Однако при трассировке запроса мы замечаем, что SQL фактически возвращает данные. По какой-то причине платформа сущностей не создает прокси-сервер, и любая ссылка на Payment.Recipient имеет значение null.

Кроме того, когда мы выполняем запрос к существующему идентификатору (один до изменения длины), мы получаем результаты без проблем.

Итак, вопросы:

1. Зачем работать локально (обе длины идентификатора), а не удаленно (на производстве)?

   • Какой тип настроек БД может быть, что будет мешать этому изменению.

2. Необработанное выполнение SQL работает в производстве, но не при создании poxy EF, почему?

Любая помощь будет потрясающей!

- добавление raw sql -

Плохой запрос

=========================================================
ID: 'bf08bdf4-a9d5-42e0-9236-a65faa4cc6ea                  '
=========================================================
SELECT 
    [Extent1].[TransactionId] AS [TransactionId],
    [Extent1].[RecipientId] AS [RecipientId],
    [Extent2].[AccountId] AS [AccountId], 
    [Extent2].[Name] AS [Name],
    FROM   [dbo].[Payment] AS [Extent1]
    INNER JOIN [dbo].[Account] AS [Extent2] ON [Extent1].[RecipientId] = [Extent2].[AccountId]
=========================================================
Recipient is null...

Хороший запрос

=========================================================
ID: 'f0e9beef                               ' 
=========================================================
SELECT 
    [Extent1].[TransactionId] AS [TransactionId],
    [Extent1].[RecipientId] AS [RecipientId],
    [Extent2].[AccountId] AS [AccountId], 
    [Extent2].[Name] AS [Name],
    FROM   [dbo].[Payment] AS [Extent1]
    INNER JOIN [dbo].[Account] AS [Extent2] ON [Extent1].[RecipientId] = [Extent2].[AccountId]
=========================================================
Recipient is not null!
RecipientId: '835cbb56                          '    
Name: John Doe

---

!! Обновление!!

Я изучаю результаты из RAW sql и обнаруживаю, что на вновь измененных свойствах сохраняются лишние пробелы...

Я наткнулся на этот пост Ро Миллер:

http://romiller.com/2014/10/20/ef6-1workaround-trailing-blanks-issue-in-string-joins/

Сообщение об укорочении строки может быть проблемой... Давайте выясним...

Answer 1

Ага,

После изменения длины поля идентификатора я получал нежелательные "пробелы" при возврате запроса LINQ to Entity.

Следуя руководству перехватчика Ро Миллера, я смог гарантировать, что все строковые поля были обрезаны по пути к базе данных.

http://romiller.com/2014/10/20/ef6-1workaround-trailing-blanks-issue-in-string-joins/

Важно отметить, что возможность ввода была доступна только недавно в EF6.1.

Надеюсь, это поможет кому-то... Я потратил 11 часов на это сегодня.