Entity Framework ConcurrencyStampがROWVERSION/TIMESTAMPを使用しないのはなぜですか？

Question

TIMESTAMPフィールドを使用して並行処理を行い、他のデータベースとの同期のためのレコードを決定するEFおよび以前に設計されたカスタムORMを初めて導入しました。

なぜEF（Core）はnvarchar（max）を使用してGuidのように見えるのでしょうか？

つまり、EFはDBが代わりに動作している可能性がありますか？

わかりやすいことは、複数のGuidをそこに格納したい場合や、ROWVERSION/TIMESTAMPが対象となるDBで一貫して実装されていないためです。 EFによって？

（似たノートに、なぜIDフィールドのデータ型はnvarchar（450）がある？）

UPDATE：

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コアアイデンティティの疑問設計上の決定ではなく、問題のように思えますEntity Frameworkコアでそれらはpublic virtual string ConcurrencyStamp { get; set; }を使用しますが、RowVersion/Timestamp列の場合、エンティティフレームワークはbyte[]を追加の注釈またはマッピングと共に使用して、更新後に値を再読み込みすることをEFが理解していることを確認します。 one of EF's own test filesから：あなた自身をEF使用する場合

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; } 
} 

、あなたは何の問題もなくRowVersion/Timestamp列を使用することができるはずです。