确定从WCF数据服务LINQ查询对Azure的FirstOrDefault请求Uri而不执行它?

时间:2010-07-27 02:59:07

标签: wcf azure azure-storage wcf-data-services

问题

我想跟踪将针对Microsoft.WindowsAzure.StorageClient.TableServiceContext对象执行的LINQ查询生成的Uri。 TableServiceContext仅使用几个属性扩展System.Data.Services.Client.DataServiceContext

我遇到的问题是,当我们在调试模式下在开发机器上运行Web角色时,查询对我们的Azure表存储实例执行正常(我们在云中连接到Azure存储而不使用Dev Storage)。我可以使用Fiddler获取生成的查询Uri,或者只是将鼠标悬停在调试器中的语句上。

但是,当我们将Web角色部署到Azure时,查询将针对具有 ResourceNotFound DataServiceClientException 的完全相同的Azure表存储源失败。在处理空表上FirstOrDefault()的行为之前,我们遇到过ResoureNotFound错误。这不是问题所在。

作为解决问题的一种方法,我想比较部署Web角色时生成的查询Uri与开发机器上运行时的查询Uri。

问题

有人知道如何在调用FirstOrDefault()方法时获取查询的查询Uri。我知道您可以在ToString()返回的IQueryable上致电TableServiceContext,但我担心的是,当调用FirstOrDefault()时,可能会进一步优化Uri并{{1} ToString()上{}可能不是调用IQueryable时最终发送到服务器的内容。

如果某人有另一种解决问题的方法,我愿意接受建议。当试图确定最终评估表达式树时会发生什么,这似乎是LINQ的一般问题。我对这里的建议持开放态度,因为我的LINQ技能可以使用一些改进。

示例代码

FirstOrDefault()

编辑更新和答案

史蒂夫提供了写答案。我们的问题正如此post中所述,其中描述了PartitionKey/RowKey ordering in Single Entity query的问题,该问题已通过Azure OS的更新得到修复。这解释了我们的开发机器与将Web角色部署到Azure之间的差异。

当我在我们的存在检查中表明我们已经处理了 ResourceNotFound 问题时,我们在代码中以两种方式处理了它。一种方法是使用异常处理来处理 ResourceNotFound 错误,另一种方法是将 RowKey 放在LINQ查询中(如某些MS人员指出的那样合适)。

事实证明,我们有几个地方首先使用 RowKey ,而不是使用异常处理。我们将通过将我们的代码重构为目标.NET 4并使用public void AddSomething(string ProjectID, string Username) { TableServiceContext context = new TableServiceContext(); var qry = context.Somethings.Where(m => m.RowKey == Username && m.PartitionKey == ProjectID); System.Diagnostics.Trace.TraceInformation(qry.ToString()); // ^ Here I would like to trace the Uri that will be generated // and sent to the server when the qry.FirstOrDefault() call below is executed. if (qry.FirstOrDefault() == null) { // ^ This statement generates an error when the web role is running // in the fabric ... } } TableServiceContext来解决这个问题。

经验教训(不止一次):不要依赖古怪的无证行为。

除了

我们能够得到查询Uri的。他们确实变得与众不同(如他们所说,他们将在博客文章中)。结果如下:

从Dev Fabric查询Uri

  

`https://ourproject.table.core.windows.net/Somethings()?$ filter =(RowKey eq'test19@gmail.com')and(PartitionKey eq'41e0c1ae-e74d-458e-8a93-d2972d9ea53c')

从Azure Fabric查询Uri

  

`https://ourproject.table.core.windows.net/Somethings(RowKey= 'test19 @ gmail.com',PartitionKey = '41e0c1ae-e74d-458e-8a93-d2972d9ea53c')

1 个答案:

答案 0 :(得分:2)

我可以做得更好......我想我知道问题是什么。 :)

请参阅http://blogs.msdn.com/b/windowsazurestorage/archive/2010/07/26/how-wcf-data-service-changes-in-os-1-4-affects-windows-azure-table-clients.aspx

具体来说,以前的客户操作系统版本(以前的客户操作系统版本)就是这样的情况:如果您按照以前的方式编写了查询(使用PartitionKey谓词之前的RowKey谓词),则会导致过滤查询(反之,PartitionKey)在RowKey之前导致了一种查询,如果结果集为空,则会引发异常。

我认为适合您的方法(如上文博文中所示)是在您的上下文中将IgnoreResourceNotFoundException设置为true。