查询 SharePoint OData 服务时在 LINQ 中使用日期比较

Question

已解答：请在下面找到我对此问题的答案。

我正在尝试使用 LINQ 从 ASP.NET MVC 3 项目使用 SharePoint 2010 OData。我使用 ASP.NET MVC 3 项目模板和 Razor 视图引擎 (VS 2010) 创建了一个默认项目。我添加了指向我的 SharePoint 2010 网站的服务引用。

在我的 HomeController 的 Index 方法（这只是一个测试项目）中，我创建了一个变量来保存上下文，并将上下文变量的 Credentials 属性设置为当前的默认凭据。

像下面这样的链接查询工作正常，我可以使用创建的变量来访问任何数据：

var query = from a in context.Alerts
            select a;

该查询只是从 SharePoint 站点中名为“警报”的列表中获取所有公告。该列表包含标题、内容、开始日期和到期日期字段。

当我将查询更改为以下内容时，我没有得到预期的结果：

var query = from a in context.Alerts
            where (a.Begins < DateTime.Now)
            select a;

此查询忽略日期的时间部分。例如，如果 a.Begins 包含昨天的日期时间，则查询返回 AlertItem。另一方面，如果 a.Begins 包含具有当前日期（但时间更早）的日期时间，则比较返回 false（并且 a.Begins == DateTime.Now 返回 true）。

如果我执行以下操作，第二个 LINQ 查询将按预期工作：

var query = (from a in context.Alerts
            select a).ToList();
var query2 = from q in query
             where (q.Begins < DateTime.Now)
             select q;

我缺少什么？

Answer 1

对于需要包含 DateTime 的时间元素的 Linq to SharePoint 查询，可以使用 TimeOfDay。

var next_slots = (from s in dc.HRDates
                  where
                  s.StartTime.HasValue &&
                  s.StartTime.Value.Date == appt.Value.Date &&
                  s.StartTime.Value.TimeOfDay == appt.Value.TimeOfDay
                  ...

Answer 2

我没有使用过SharePoint 2010的OData。但是，在针对 SharePoint 2010 对象模型进行查询时，您发布的异常是一种常见行为，回复：您必须先将查询转换为列表，然后才能查询数据。

这里的典型模式是：

var query = someSharePointQuery.ToList();

var results = query.Where(...).First(...);

看起来很奇怪，但这就是 SP 2010 的工作原理。

Answer 3

DateTime.Today 是否在某处被使用？我用 LinqPad 做了一些原型设计，复制结果的唯一方法是使用“where (a.Begins < DateTime.Today)”进行查询，

这是我对您所描述的内容所做的快速草图：

void Main()
{
    List<Alerts> alerts = new List<Alerts>();
    alerts.Add(new Alerts(DateTime.Now.AddDays(-1)));
    alerts.Add(new Alerts(DateTime.Now));

    var query = from a in alerts
                where (a.Begins < DateTime.Now)
                select a;
    foreach (var element in query)
    {
        Console.WriteLine(element.Begins);
    }

}
public class Alerts
{
    public DateTime Begins {get; set;}
    public Alerts(DateTime begins)
    {
        Begins = begins;
    }
}

正如我所提到的，复制您所描述的结果的唯一方法是我将 where 子句中的 DateTime.Now 更改为 DateTime.Today 。我会检查您的代码是否意外使用了错误的 DateTime 方法。

顺便说一句，我强烈建议使用 LinqPad 来构建 Linq 查询的原型...它可以让您快速迭代代码并找出问题所在，从而节省您的时间。此外，它还非常值得花 50 美元购买智能感知和其他高级功能。

Answer 4

在将来自许多不同来源的信息拼凑在一起后（没有一个来源涉及我遇到的问题的具体情况），我得出以下结论：

使用 SharePoint 对象模型和协作应用程序标记查询 SharePoint 数据时语言 (CAML)，SharePoint 默认情况下在进行比较时不使用 DateTime 元素的时间组件。要告诉 SharePoint 使用时间组件，必须在值类型中包含 IncludeTimeValue = 'TRUE' 属性，如下所示：

<Where>
 <Eq>
  <FieldRef Name='Begins' />
  <Value Type='DateTime'  IncludeTimeValue='TRUE'>
   2008-03-24T12:00:00Z
  </Value>
 </Eq>
</Where>

我发现有几篇博客文章引用了 LINQ to SharePoint 中的一个错误，该错误导致生成的 CAML 输出为：

<Where>
 <Eq>
  <FieldRef Name='dateTimeField'  IncludeTimeValue='TRUE' />
  <Value Type='DateTime'>
   2008-03-24T12:00:00Z
  </Value>
 </Eq>
</Where>

请注意， IncludeTimeValue = 'TRUE' 位于 FieldRef 元素而不是 Value 元素上。由于这不是该属性的正确位置，因此它会导致所有执行日期时间比较的 LINQ to SharePoint 查询仅对日期组件进行比较。

由于我在使用 LINQ 和 WCF 数据服务连接到 SharePoint 时看到完全相同的行为，因此我只能假设 LINQ/WCF 数据服务在幕后生成相同的无效 CAML。

解决方案（假设我仍然想使用 LINQ/WCF 数据服务）是执行两个查询（如原始问题中所述）。第一个 LINQ 查询从 SharePoint 中提取列表数据并将其存储在列表中。第二个 LINQ 查询处理日期比较，仅提取我想要的数据。

由于在我的特定情况下，我可能在 SharePoint 列表中有许多条目涵盖很长的时间跨度，但只对特定一天或几天的条目感兴趣，我想找到一种方法不带回整个列表第一个查询。

我决定进行 <= 和 >= 比较以接近，然后在第二个查询中进一步限制它。所以我的两个查询现在变成：

DateTime RightNow = DateTime.Now;
var query = (from a in context.Alerts
             where (a.Begins <= RightNow) && (a.Expires >= RightNow)
             select a).ToList();
var query2 = from q in query
             where q.Begins < RightNow) && (a.Expires > RightNow)
             select q;

第一个 LINQ 语句将返回我最终感兴趣的所有项目；以及一些我不是的（因为它只比较日期时间的日期部分）。第二个 LINQ 语句将进一步将其精简为我感兴趣的内容。

Answer 5

我可以确认 SharePoint 2010 LINQ to SharePoint 未创建正确的 CAML（将 IncludeTimeValue='True' 添加到 FieldRef 而不是值）的错误已由 SharePoint Foundation 2010 的 2013 年 10 月累积更新修复。该修补程序可以从http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx。

SharePoint 2013 中也存在相同的错误，Microsoft 支持人员通知我应该在 2013 年 12 月的 SharePoint Foundation 2013 累积更新中修复该错误，但我无法确认这一点。我被告知该修复程序也已部署到 Office 365，但我无法确认这一点。