Entity Framework SET IDENTITY_INSERT - PullRequest
       1

Entity Framework SET IDENTITY_INSERT

5 голосов
/ 21 января 2011

Есть ли способ принудительно установить значение идентификатора для новой сущности в EF, когда у нас есть столбец идентификатора с автоинкрементом, т.е. использовать поведение SET IDENTITY_INSERT через EF?

Наше требование состоит в том, что наша форма создания должнавсегда отображайте новый, уникальный идентификатор объекта, который мы создаем, в пустой форме перед ее заполнением или сохранением.Идея заключается в том, что этот идентификатор может быть прочитан кому-либо по телефону, а затем пользователь может заполнить и сохранить форму после завершения вызова.Мы могли бы зарезервировать идентификатор, вставив туда пустую строку в базу данных, но у нас есть уникальные столбцы и FK;вместо этого я создал таблицу «следующего идентификатора», которую мы увеличиваем с помощью блокировок для безопасности, и я проверяю ее по верхнему идентификатору в таблице объектов, чтобы быть осторожным.Идея заключалась в том, чтобы затем принудительно использовать этот новый идентификатор, когда мы перезаписываем сущность, но я не понимаю, как заставить EF сделать это.

Возможно ли это - это просто то, что япропущенный?Я не думаю, что идентификатор даже делает это до вставки, поэтому я не думаю, что ручной вызов SET IDENTITY_INSERT вокруг SaveChanges помог бы.

Или я должен сделать что-то еще?Я вижу альтернативы:

  • Измените наш столбец идентификаторов, чтобы он не был идентификатором, и возьмите все это под контроль вручную: здесь есть наследование идентификатора таблицы, так что это тоже может быть сложно.
  • Разделите идентификатор БД и видимый пользователем идентификатор в отдельном столбце и запишите наш уникальный идентификатор там.
  • Пустая строка для резервирования идентификатора, как указано выше;возможно, потребуются некоторые изменения обнуляемости и внесение поправок в наш код чтения данных, чтобы игнорировать эти записи.

Спасибо!Это EF4 (с использованием EDMX и сгенерированных классов, а не POCO), и в случае SQL Server 2008 это имеет значение.

Ответы [ 2 ]

1 голос
/ 21 января 2011

Почему бы не использовать Guid в качестве первичного ключа. Ничего общего с автоинкрементом, ловушками параллелизма и т. Д. Вы просто создаете Guid в момент создания формы. Отдайте его абоненту и заполните форму позже. Когда форма отменяется, нет проблем. Когда форма закончена, создайте сущность с созданным Guid, установите другие значения объекта сущности, примените его к контексту (a) и SaveChanges () ...

0 голосов
/ 06 мая 2017

Альтернативы, которые не изменят вашу схему

  1. Использовать транзакцию EF

Вы можете вызвать context.SaveChanges () и получить автоинкрементированный первичный ключ. После завершения процесса вы можете совершить транзакцию. Если транзакция отменяется или возникает ошибка / исключение, вы всегда можете выполнить откат, чтобы в ваших строках не было дыр / грязных данных. Я предлагаю вам использовать шаблон синглтона и передавать ту же транзакцию / контекст любым методам или экранам для завершения процесса.

  1. Просто добавьте дополнительный статус: Черновик

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...