OData 客户端未使用 $expand 进行补水

Question

我使用 OData 一段时间了，发现它是设置服务器的绝佳工具。今天我遇到了一些我以前从未见过的东西，这让我感到非常困惑。

我在客户端上使用 .Expand 来请求获取报告时的数据树。我已经在原型中使用了精确的查询，并且效果非常好（即完全水合）。当我使用 Fiddler 发送查询时，响应数据包是完美的，并且包含我正在查找的所有数据。

问题在于，客户端尚未对任何扩展属性进行水合（服务引用与当前服务完全最新）。为了尝试弄清楚发生了什么，我将范围缩小到单个属性，但它仍然不起作用。

var report = (serviceContext.Reports.Expand("ReportAreas").Where(r=>r.ReportID==reportID)).SingleOrDefault();

给我报告，但 ReportAreas 包含 0 个项目。如果我随后尝试：

serviceContext.LoadProperty(report,"ReportAreas");

那么 ReportAreas 包含 20 个左右的项目。

这让我非常疯狂，因为 Expand 正在为不同的对象树（不同的查询但相同的功能代码）工作，没有任何问题。有人对我如何弄清楚这里到底发生了什么有建议吗？？？

更新：

今天关于此的一些新信息可能更奇怪，并向我暗示 OData 客户端中存在错误。我发现只有报表对象的子集会返回，而不会填充扩展属性。数据库中的大多数报告都非常好。即，如果我请求扩展了 ReportAreas 的所有报告（而不是细化为单个 reportID），则大约 80-90% 的 ReportAreas 计数为非零，其余部分为 0。

当返回的报告没有填充任何属性时（null或 0 计数）实际属性对象正在被实例化并且它们的属性正在被设置（从服务引用的 Reference.cs 文件中的断点），因此，例如属于 ReportArea 对象的 ReportID、PropertyAreaID 和 History 值被设置 16 次在查询解析期间，但在请求时 ReportAreas 列表的计数为 0。当我使用 _service.LoadProperty 时，它返回 16 个 ReportAreas。

在我看来，扩展查询中的引用不匹配，但它太一致了，不可能是一个简单的问题。有效的报告始终有效，无效的报告永远无效。真的希望有人能帮助我查明这一点，以便我可以继续进行一些有用的编码......

Answer 1

这个问题的解决方案（至少在我更好地理解之前）是设置

serviceContext.MergeOption = MergeOption.OverwriteChanges;

我被告知这与客户端不重新补充链接（如果它们已经被跟踪）有关。如果我发现更多/更好地理解问题，我会更新这个答案。