Проблема с подходом атрибута ConcurrencyCheck в EF - PullRequest
Новая
       12

Проблема с подходом атрибута ConcurrencyCheck в EF

4 голосов
/ 22 апреля 2011

Я нашел два способа проверки параллельности для моих сущностей в EF 4.1:

  • Атрибут TimeStamp для байтового массива
  • Атрибут ConcurrencyCheck для других типов

Первый очень прост.Вы просто помечаете свойство байтового массива как TimeStamp, создаете дополнительный столбец в базе данных и вуаля ...

У меня проблема со вторым методом.Enity Framework начал генерировать sql-скрипт для проверки параллелизма, когда я отметил свойство LastUpdateDate.

Свойство: 

[ConcurrencyCheck]
public DateTime LastUpdateDate { get; set; }

Sql: 

select
...
where (([Id] = @3) and ([LastUpdateDate] = @4))
...
@4='value'

Но EF не делаетсоздать сценарий sql для обновления значения LastUpdateDate?

Можно ли сказать, что EF обновляет LastUpdateDate после проверки параллелизма без триггеров или что-то в этом роде?

И второй вопрос: что такоенаилучшая практика использования проверки параллельности в EF, когда у вас есть что-то вроде свойства LastUpdateDate (свойство будет отображаться в пользовательском интерфейсе)?Лучше проверить параллелизм с помощью LastUpdateDate и избежать создания дополнительного столбца для TimeStamp в ваших таблицах или создать дополнительное свойство TimeStamp и отказаться от использования свойства DateTime для проверки параллелизма?

1 Ответ

3 голосов
/ 22 апреля 2011

Вы пытались использовать версию строки (метку времени) вместо типа данных DateTime для проверки совпадения?

Я бы использовал метку времени, потому что вы уверены, что система обновит ее для вас.Далее значение будет очень точным.

Следующие сообщения в блоге дадут вам больше информации о том, как сопоставить отметку времени.Первый показывает, как использовать метку времени в качестве проверки параллелизма.

Код Первый оптимистический параллелизм с текущими утверждениями

Круговое отключение поля метки времени с EF4.1 Code First и MVC 3

...