.NET Core создает необнуляемое ограничение FK с помощью IdentityUser - PullRequest
0 голосов
/ 28 января 2019

Я пытаюсь создать связь между моим основным IdentityUser и другим классом, используя миграции EF в .NET Core 2.2.Есть проблема, с которой я сталкиваюсь, и это то, что миграции создаются с ограничением null FK.Это то, чего я не хочу.

Боюсь, что мне не следует вручную редактировать файл миграции (чтобы исправить эту проблему), так как при изменении этих моделей в будущем мое ручное редактирование будет перезаписано(потому что мои классы каким-то образом закодированы неправильно).

Это те классы, которые у меня есть ..

public class ApplicationUser : IdentityUser
{
    public List<Purchase> Purchases { get; set; }
}

public class Purchase
{
    public int Id { get; set; }
    // others
}

Полученный файл миграции имеет набор свойств nullable: true в ApplicationUserId

migrationBuilder.CreateTable(
            name: "Purchase",
            columns: table => new
            {
                Id = table.Column<int>(nullable: false)
                    .Annotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn),
                ApplicationUserId = table.Column<string>(nullable: true)
            },
            constraints: table =>
            {
                table.PrimaryKey("PK_Purchase", x => x.Id);
                table.ForeignKey(
                    name: "FK_Purchase_AspNetUsers_ApplicationUserId",
                    column: x => x.ApplicationUserId,
                    principalTable: "AspNetUsers",
                    principalColumn: "Id",
                    onDelete: ReferentialAction.Restrict);
            });

Не правильно.Итак, я добавляю свойства в класс Purchase (как и в других POCO в моем проекте) ..

public class Purchase
{
    public int Id { get; set; }
    // others

    public int ApplicationUserId { get; set; }
    public ApplicationUser ApplicationUser { get; set; }
}    

и перезапускаю регенерацию миграции ..

migrationBuilder.CreateTable(
            name: "Purchase",
            columns: table => new
            {
                Id = table.Column<int>(nullable: false)
                    .Annotation("SqlServer:ValueGenerationStrategy", SqlServerValueGenerationStrategy.IdentityColumn),
                ApplicationUserId = table.Column<int>(nullable: false),
                ApplicationUserId1 = table.Column<string>(nullable: true)
            },
            constraints: table =>
            {
                table.PrimaryKey("PK_Purchase", x => x.Id);
                table.ForeignKey(
                    name: "FK_Purchase_AspNetUsers_ApplicationUserId1",
                    column: x => x.ApplicationUserId1,
                    principalTable: "AspNetUsers",
                    principalColumn: "Id",
                    onDelete: ReferentialAction.Restrict);
            });

Теперь я получаю надлежащее ненулевое ограничение, но это дубликат.(Есть 1 прикрепленный).Мои вопросы:

  1. Безопасно ли мне просто изменить файл миграции и назвать его днем?
  2. Как я могу создать отношения между моими ApplicationUser и Purchase классы, так что созданный файл миграции дает мне необнуляемое ограничение FK?

1 Ответ

0 голосов
/ 28 января 2019

1) Вы можете, но каждая последующая миграция будет переделывать это поле и вызывать проблемы.Также, поскольку тип данных не совпадает, он не будет работать должным образом

2) Неверный тип идентификатора внешнего ключа.У пользователя приложения есть первичный ключ типа string, но вы используете int, поэтому он не может распознать правильный внешний ключ.

После того, как вы исправите это, поместите атрибут Обязательный в класс.Таким образом, последний класс будет выглядеть как

using System.ComponentModel.DataAnnotations;

public class Purchase
{
    public int Id { get; set; }
    // others

    [Required]
    public string ApplicationUserId { get; set; }
    public ApplicationUser ApplicationUser { get; set; }
} 
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...