Breeze создает дублированный объект в локальном кеше после сохранения на сервере

У меня такая же проблема, как описано в New Breeze 1.4.9 - Дублируемая сущность - возможная ошибка? , однако эта проблема была сообщена как вызванная ошибкой с момента исправления. Я использую v1.4.11.

Я нахожу, что, когда я сохраняю новый объект Breeze на сервере, он реагирует на успешный ответ с сервера, создавая новый дублированный объект вместо обновления существующего. Я запускаю следующий тестовый код по очереди в консоли браузера, из состояния отсутствия сущностей в кеше Бриз.

EntityManager.createEntity("CustomGroup", properties);
EntityManager.getChanges(); =>
 0:
 Id="b0cb3194-35af-4d23-9e77-d192c907b566"
 EntityState=Added

Все идет нормально. Как и ожидалось, в ожидающем массиве изменений есть один объект.

EntityManager.saveChanges(); =>
 KeyMappings:
 0:
 TempValue="b0cb3194-35af-4d23-9e77-d192c907b566"
 RealValue="f056f519-9f11-4375-a0dd-5272a11b9b46"

После выполнения saveChanges() сервер возвращает объект KeyMapping с значениями temp и real key. На этом этапе перечисление всех объектов в кеше обнаруживает неожиданный результат:

EntityManager.getEntities(); =>
 0:
 Id="f056f519-9f11-4375-a0dd-5272a11b9b46"
 EntityState=Added
 1:
 Id="b0cb3194-35af-4d23-9e77-d192c907b566"
 EntityState=Unchanged

Таким образом, в то время как Breeze изменил состояние исходного объекта на "Без изменений" в ответ на его сохранение на сервере, он не обновил его новым ключом и вместо этого создал дубликат объекта с использованием нового ключа, который, по его мнению, он все равно должен сохранять.

Второй вызов saveChanges() отправляет новый запрос на сервер, который отвечает с помощью объекта KeyMapping, который имеет идентичные TempValue и RealValue, и в этот момент Breeze решает, что изменений больше нет, хотя объект-изгои остается в кеше, конечно,

2 ответа

Хорошо, я понял это. Объект, возвращенный сервером в ответе от SaveChanges, имел временное значение ключа, когда он должен иметь новое значение, генерируемое сервером. Я заметил это, но предположил, что это правильное поведение и будет выяснено Бризом, используя KeyMapping, после получения ответа.

Я не вижу ничего в Breeze.ContextProviderEF6.EFContextProvider.cs, который изменяет значение ключа для отправленного объекта, так что это может произойти автоматически в EntityFramework, но мы должны сделать это вручную в нашем пользовательском LightSpeed ContextProvider.


Я посмотрел на ваш Metadata.json, и я думаю, что проблема есть. Иногда метаданные OData не предоставляют достаточной информации. В этом случае я не думаю, что клиент Breeze знает, что ContentGroup имеет автоматически сгенерированный ключ.

Обычно мы рекомендуем использовать WebApi Breeze ContextProvider и BreezeControllerAttribute вместо OData на сервере. См. Документацию Breeze по нескольким причинам.

licensed under cc by-sa 3.0 with attribution.