Breeze 微风提取导致未映射的原始值丢失

我有一个例子，当第二次获取一个breeze实体时，该实体会丢失其未映射属性的

原始值。

我知道为什么会这样我只是觉得不应该

由于breeze发现实体未被修改，并正确地合并到来自服务器的传入值中，因此在后续获取时，
原始值将被清除。但是，我的实体具有已更改的未映射属性，其原始值存储在
originalValues
hash中。这些正在清理中

我可以理解一个论点，它说这应该是
MergeStrategy
设置为
OverwriteChanges
时的行为

然而，清除
原始值
时使用
合并策略
的
保留更改。我认为这种行为不是一个好主意

使用
PreserveChanges
的
MergeStrategy
，当一个实体被认为是未修改的，等等，并且传入的值被合并进来时，我认为不应该清除
原始值

现在可以通过使用
SkipMerge
的
MergeStrategy
进行设置来解决问题，但是这会导致问题，因为实体永远不会用传入值刷新

那么这种行为可以改变吗

谢谢

Christian
一个非常有趣的用例。。。一个值得认真思考的问题

当
MergeStrategy
为“PreserveChanges”时，让我们了解一下合并查询结果的语义

首先，一些意见：


当您更改未映射属性时，Breeze不会更改
EntityState

Breeze在
OriginalValues
中保留未映射属性的更改前值


让我们考虑一下微风如何合并查询结果：

当
实体状态
处于更改状态时，所有属性（已映射和未映射）都将保留，即使相应的查询属性值不同

当
实体状态
为“未更改”时，所有属性（已映射和未映射）将被替换为查询结果有效负载中发现的相应查询属性值


Breeze不支持部分合并。它不会覆盖某些属性并保留其他属性。

我不知道为什么查询处理会清除
原始值
（我说这还没有研究过它，甚至没有确认它确实如此）。但我认为这是在做正确的事情

请考虑将任何属性合并到一个未更改的实体中时的含义。假设查询前属性
foo
为1，新查询的值为2

随后，我们将
foo
设置为3。当时的“原值”应该是什么？应该是2，对吗？不应该是1。它应该是从服务器检索到的最后一个值

因此，合并后，原始值与实体的最新值隐式相同。也就是说，如果一个属性在
OriginalValues
中有一个值，那么它应该与相应的当前值相同。如果当前值===原始值，我们不妨从
原始值中删除该属性。。。这意味着清除该属性的
原始值
是无害的

由于Breeze执行完全合并（而不是部分合并），因此清除整个
原始值是一致的行为。

根据这条推理——如果您认为映射和未映射的属性应该遵循相同的合并规则——Breeze做的事情完全正确

也许您希望将对未映射属性的更改视为对
EntityState
的更改

我认为我们在过去曾经这样做过，但是我们确信
实体状态
应该只反映映射的属性的更改，这些属性被假定为持久属性

至少在您的特定用例中，您似乎不同意。我认为（请确认）当您更改未映射属性时，您希望Breeze将该实体视为“脏”

幸运的是，你可以自己处理。向
EntityManager.entityChanged
事件添加处理程序，并在更新未映射属性时更改
EntityState
。您可以广泛地或有选择地这样做

如果您真的要对映射和未映射的属性进行不同的处理，您将面临一个艰难的过程。我们当然会听。。。但你得好好辩论一番

您可以进一步提出更通用的建议，例如新的
MergeStrategy
，它支持开发人员定义的自定义策略

也许我们应该扩展元数据，这样您就可以指定一个合并函数来控制Breeze如何合并给定
EntityType
的属性。那太酷了

这将是一个重要的新特性，需要大量的测试。我认为这需要很多说服才能让它出现在黑板上。
WRT在未映射属性更改时设置entity dirty：对于计算属性（服务器计算并发送给客户端的值，服务器从不使用客户端的值），更改客户端的值是没有意义的。如果实体未设置为脏的，则看起来很好。由于服务器不使用该值，因此实体不需要保存。但是，如果客户端可能使用未映射属性与服务器通信（这是允许的/可能的吗？），则应更改该属性