Блог

Главная - Вопросы по программированию - EF Core 3.1 — Сопоставление отношений 0..1, в которых зависимый имеет общий ПК

EF Core 3.1 — Сопоставление отношений 0..1, в которых зависимый имеет общий ПК

#c# #entity-framework-core #ef-core-3.1

Вопрос:

У меня возникла ситуация, когда я не смог правильно извлечь свой зависимый класс с помощью включения в EF Core 3.1 при извлечении основного. Эта ситуация может немного отличаться от документов MS, так как в зависимом классе PK и FK находятся в одном поле, FileDefinitionId

Несмотря на весь приведенный ниже код, определение файла.Значение FileImportDefinition равно null.

Есть ли что-то, что я упустил? Я следил за документами Microsoft по этому вопросу

             fileDefinition = context.FileDefinitions
                .AsNoTracking()
                .Include(x => x.FileImportDefinition)
                .FirstOrDefault(p => p.FileDefinitionId == fileDefinitionId);

Главный

 public partial class FileDefinition
{
    public long FileDefinitionId { get; set; }
    
    public virtual FileImportDefinition FileImportDefinition { get; set; }
}

Зависимый

 public partial class FileImportDefinition
{
    public long FileDefinitionId { get; set; }
    public virtual FileDefinition FileDefinition { get; set; }
}

OnModelBuilding — определение файла (принципал)

             entity.HasOne(d => d.FileImportDefinition)
                .WithOne(p => p.FileDefinition)
                .IsRequired(false)
                .HasForeignKey<FileImportDefinition>(d => d.FileDefinitionId)
                .HasConstraintName("FK_FileImportDefinitions_FileDefinitions")
                .OnDelete(DeleteBehavior.ClientSetNull);

Комментарии:

1. «как и в зависимом классе, PK и FK находятся в одном поле» На самом деле это (называемое общей ассоциацией PK) является значением по умолчанию для отношений EF Core один к одному. Ваш пример работает для меня (EFC 3.1.19, SQLServer) — свойство навигации загружено, как и ожидалось. У вас есть некоторые конфликтующие / неприменимые конфигурации для этого типа отношений ( IsRequired(false) , DeleteBehavior.ClientSetNull ), которые обычно игнорируются EFC, но безопаснее не полагаться на это, т. Е. Удалить первую (PK всегда требуется) и изменить вторую на DeleteBehavior.Restrict .

2. Спасибо @IvanStoev, я бы определенно отметил это как ответ, если бы мог. Еще одна проблема, которую я заметил, заключалась в том, что мой класс использовал System.Data.Entity вместо Microsoft. EntityFrameworkCore для методов контекстной компоновки (проект миграции EF6 > EFCore)

Метки: ,