Отладка объектов самопроверки - исключение AcceptChanges из-за конфликта значений ключа объекта с другим объектом в ObjectStateManager

Question

Возникла исключительная ситуация при сохранении изменений в объекте самообследования:

AcceptChanges cannot continue because the object's key values conflict with another object in the ObjectStateManager. Make sure that the key values are unique before calling AcceptChanges.

Я полагаю, что проблема решена в других вопросах, таких как: Самопроверка объектов - AcceptChanges не может продолжаться, потому что значения ключа объекта конфликтуют с другим объектом в ObjectStateManager

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

Если нет, то придется ли мне что-то писать для обхода графа объектов в поисках дублирующих ключей, ссылающихся на разные объекты? Если да, то есть ли у кого-нибудь такой опыт?

Дополнительная информация:

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

Представления в клиенте используют предварительно выбранные объекты для статических данных, таких как таблицы поиска для производительности. Если мы скажем объект Customer с FK для пользователя, он будет загружен при получении из службы. Если мы теперь добавим еще один объект в граф объектов, например, Закажите и установите свойство User для этого объекта, который имеет тот же Id, что и в объекте Customer, но объект был извлечен в другой точке и, следовательно, с использованием другого ObjectContext (т. Е. Объекты имеют тот же Id, но не являются тем же экземпляром объект) Я получаю эту ошибку.

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

Answer 1

Я бился головой об эту проблему больше часов, чем я хотел признать. Наконец, выяснилось, что причиной проблемы было то, что я выслушал подсказку ReSharper, чтобы сделать мой поставщик контекста статический. так как это произошло с множеством других изменений, я не думал проверять это как виновника. Но в моем случае это была проблема.

Answer 2

Обычно это происходит, если вы пытаетесь AcceptChanges в контексте, который использовался для загрузки объектов ранее - используйте новый пустой контекст для принятия изменений. AcceptChanges нельзя использовать, когда какой-либо объект из STE уже загружен в контексте - это ограничение текущей реализации STE (но, вероятно, его можно удалить, если переписать шаблон).

Как я знаю, нет подробных исключений для такого рода проблем. Для отладки STE проверьте их сгенерированный код. У вас есть весь код STE, так что вы можете просматривать трекер изменений и искать сущности, но это будет непросто.

На самом деле я не уверен, возможно ли даже определить дубликаты на клиенте, но давайте предположим, что это так. Если у вас есть контроль над клиентским кодом, лучше всего диагностировать клиентский код. Добавьте запись в журнал и найдите причину дублирования. Затем удалите дублирование, потому что устранить проблему на клиенте будет проще, чем устранить проблему в службе. Если у вас нет контроля над клиентом, я бы сказал, что это проблема неправильных данных, передаваемых вашему клиенту, и позволил разработчикам клиента это исправить.