Question

我是EF的新手，以前设计的自定义ORM使用TIMESTAMP字段进行并发，并确定与其他数据库同步的记录。

为什么EF（Core）使用nvarchar（max）存储看起来像Guid的内容？

即。为什么EF会像DB那样工作呢？

显而易见的是在某些时候（可能在扩展到多个服务器/数据库时）我们希望在那里存储多个Guid，和/或可能只是因为ROWVERSION / TIMESTAMP并未在目标数据库上一致地实现EF？

（在类似的说明中为什么ID字段为nvarchar（450）？）

更新：

migrationBuilder.CreateTable(
    name: "AspNetRoles",
    columns: table => new
    {
        Id = table.Column<string>(nullable: false),
        ConcurrencyStamp = table.Column<string>(nullable: true),
        Name = table.Column<string>(maxLength: 256, nullable: true),
        NormalizedName = table.Column<string>(maxLength: 256, nullable: true)
    },
    constraints: table =>
    {
        table.PrimaryKey("PK_AspNetRoles", x => x.Id);
    });

Answer 1

这似乎是ASP.NET核心标识的可疑设计决策，而不是实体框架核心中的问题。他们使用public virtual string ConcurrencyStamp { get; set; }，但对于RowVersion / Timestamp列，实体框架使用带有附加注释或映射的byte[]来确保EF理解该值应在之后重新读取更新。来自one of EF's own test files：

public class Two
{
    [Key]
    public int Id { get; set; }

    [StringLength(16)]
    public string Data { get; set; }

    [Timestamp]
    public byte[] Timestamp { get; set; }

    public virtual C NavC { get; set; }
}

如果您自己使用EF，则应该能够毫无问题地使用RowVersion / Timestamp列。

为什么Entity Framework ConcurrencyStamp不使用ROWVERSION / TIMESTAMP？

1 个答案: