Почему Entity Framework ConcurrencyStamp не использует ROWVERSION/TIMESTAMP?

Я новичок в EF и ранее разработанных пользовательских ORM, которые используют поля TIMESTAMP для параллелизма, а также определяют записи для синхронизации с другими базами данных.Почему Entity Framework ConcurrencyStamp не использует ROWVERSION/TIMESTAMP?

Почему EF (Core) использует nvarchar (max) для хранения того, что выглядит как Guid?

Т.е. почему EF работает, что БД может делать вместо этого?

Очевидная вещь в какой-то момент (возможно, при масштабировании до нескольких серверов/баз данных) мы хотим хранить в ней несколько гидов и/или, возможно, просто потому, что ROWVERSION/TIMESTAMP не выполняется последовательно на целевых БД по EF?

(на аналогичную ноту, почему это идентификатор поля 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); 
    });

источник

2016-12-08 Etherman

Для этого EF не должен использовать 'nvarchar (MAX)', а в EF6 - нет. Там может быть проблема конфигурации где-то, но если это действительно изменилось в EF Core, я подозреваю, что это ошибка, а не функция. Можете ли вы показать определение и сопоставление классов и сгенерированную таблицу? Кроме того: «(по аналогичной заметке, почему поле идентификатора nvarchar (450)?)» - это не связано и, вероятно, лучше всего оставить без внимания, но обратите внимание, что вы должны обнаружить проблему в предупреждениях SQL Server, если вы просто сделаете это 'nvarchar (MAX)' вне EF. – hvd

Вот еще одно сообщение с снимком экрана типов данных: http://stackoverflow.com/questions/34252640/what-is-the-purpose-of-the-concurrencystamp-column-in-the-aspnetusers-table-in- t – Etherman

Это кажется сомнительным дизайнерского решения ASP.NET ядра Identity, не проблема в ядре Entity Framework. Они используют public virtual string ConcurrencyStamp { get; set; }, но для столбцов /Timestamp Entity Framework использует 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 столбцы без каких-либо проблем.

источник

2016-12-08 08:54:32 hvd

Я обычно виноват в попытке внедрить новые рамки в спешке, а затем повторно изобретать колесо (без сомнения), когда я не понимаю какой-то стандарт/соглашение. Я пытаюсь избежать этого. Должна быть некоторая причина использовать строки здесь, мне интересно, что это значит, поскольку значительная часть моего проекта будет включать масштабируемые параллелизм и проблемы синхронизации. Но я согласен с вами, теперь выглядит мне как выбор дизайна в Identity, а не EF. – Etherman

Почему Entity Framework ConcurrencyStamp не использует ROWVERSION/TIMESTAMP?

ответ

Смежные вопросы