Question

我遇到与New Breeze 1.4.9 - Duplicate entity - possible bug?中描述的问题相同的问题，但据报道该问题是由自修复后的错误引起的。我使用的是v1.4.11。

我发现当我将新的Breeze实体保存到服务器时，它会通过创建一个新的重复实体而不是更新现有实体来响应服务器的成功响应。我在浏览器控制台中逐行运行以下测试代码，来自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对象。此时，列出缓存中的所有实体会显示意外结果：

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

所以，虽然Breeze已经将原始对象的状态更改为＆＃34; Unchanged＆＃34;为了响应被保存到服务器，它没有使用新密钥更新它，而是使用新密钥创建了一个重复的实体，它认为它仍然需要保存。

对saveChanges（）的第二次调用向服务器发送一个新请求，该服务器使用具有相同TempValue和RealValue的KeyMapping对象进行响应，此时Breeze决定不再有更改，尽管恶意实体仍在缓存当然。

Answer 1

我看了你的Metadata.json，我觉得问题就在那里。 OData元数据有时无法提供足够的信息。在这种情况下，我不认为Breeze客户端知道ContentGroup有一个自动生成的密钥。

我们通常建议在服务器上使用WebApi Breeze ContextProvider和BreezeControllerAttribute而不是OData。有关更多原因，请参阅Breeze Documentation。

Answer 2

好的，我已经明白了。服务器在SaveChanges响应中返回的实体具有临时键值，当它应具有新的服务器生成值时。我注意到了这一点但是假设它是正确的行为，并且在接收到响应时将使用KeyMapping由Breeze整理出来。

我在Breeze.ContextProviderEF6.EFContextProvider.cs中看不到任何修改提交实体的键值的内容，因此这可能是在EntityFramework中自动发生的事情，但我们需要在自定义LightSpeed ContextProvider中手动完成

保存到服务器后，Breeze在本地缓存中创建重复实体

2 个答案: