我有一个案例，当第二次获取该实体时， breeze实体失去了未映射属性的originalValues。
我知道为什么这种情况正在发生我只是不认为应该这样做。
originalValues在后续提取时被清除，因为breeze看到该实体未被修改并正确合并来自服务器的传入值。但是，我的实体具有已更改的未映射属性，其原始值存储在originalValues哈希中。这些都被清除了。
我可以理解一个论点，即这应该是MergeStrategy设置为OverwriteChanges的行为。
但是，对originalValues MergeStrategy PreserveChanges进行清除MergeStrategy。我认为这种行为不是一个好主意。
如果PreserveChanges为originalValues，当某个实体被视为未修改时，等等，并且传入的值已合并，我认为不应该清除MergeStrategy。
现在可以使用SkipMerge {{1}}进行设置，但这会导致问题，因为实体永远不会刷新传入值。
那么这种行为可以改变吗？
由于
基督教
答案 0 :(得分：1)
一个非常有趣的用例......一个值得认真反思的用例。
当MergeStrategy为＆＃34; PreserveChanges＆＃34;时，让我们来看看合并查询结果的语义。
首先，一些观察结果：
更改未映射的属性时，Breeze不会更改EntityState
Breeze DOES保留OriginalValues中未映射属性的更改前值。
让我们考虑一下Breeze如何合并查询结果：
当EntityState处于更改状态时，所有属性（已映射和未映射）仍然保留如果相应的查询属性值不同。
当EntityState为＆＃34;未更改＆＃34; 时，所有属性（已映射和未映射）已替换< / strong>通过在查询结果有效负载中发现的相应查询属性值。
Breeze不支持部分合并。它不会覆盖某些属性并保留其他属性。
我不知道某些为什么查询处理会清除OriginalValues（我说没有查看它甚至确认它确实存在）。但我认为这是正确的做法。
考虑将 任何 属性合并到未更改的实体时的含义。假设查询前属性foo为1，新查询值为2.
随后，我们将foo设置为3.＆＃34;原始值＆＃34;那个时候？它应该是2，对吗？它不应该是1.它应该是从服务器检索的最后一个值。
接下来，在合并之后，原始值与实体的最新值隐含地相同。也就是说，如果属性的值为OriginalValues，则它应与相应的当前值相同。如果当前值===是原始值，我们也可以从OriginalValues中删除该属性...这意味着清除该属性的OriginalValues是无害的。
由于Breeze执行完整合并（不是部分合并），因此清除整个
OriginalValues是一致的行为。
根据这种推理 - 如果您认为映射和未映射的属性应遵循相同的合并规则 - Breeze正在做正确的事情。
也许您想要的是将对未映射属性的更改视为对EntityState的更改。
我认为我们过去曾经这样做过，但我们确信EntityState只应反映对映射属性的更改，这些属性被认为是持久< / em> properties。
您似乎不同意，至少在您的具体用例中。我认为（请确认）当您更改未映射的属性时，您希望Breeze将实体视为＆＃34;脏＆＃34;。
幸运的是，你可以自己处理。向EntityManager.entityChanged事件添加处理程序，并在更新未映射的属性时更改EntityState。你可以广泛或有选择地做到这一点。
如果您真的寻求对映射和未映射属性的不同处理，那么您将进行爬坡。我们当然会倾听......但你必须做出一个很好的争论。
您可以通过提出更具通用性的内容来进一步提升，例如支持 开发人员定义的自定义政策 的新MergeStrategy。
也许我们会扩展元数据，以便您可以指定一个合并函数来控制Breeze如何合并给定EntityType的属性。那会很酷。
这将是一项重要的新功能，需要大量测试。我认为这需要很多说服才能在董事会上获得这个。