我有一个相当大的数据模型,我想使用OData V4协议使用Web API OData公开.
基础数据存储在SQL Server 2012数据库中.该数据库中包含许多DateTime列.
当我接线时,我收到一个错误,即不支持System.DateTime.
所以这是我的问题,我该怎么做才能在OData Feed中看到我的DateTime列？
注意:我无法返回并将所有列更改为DateTimeOffset列.
我尝试更改Entity Framework edmx中列的类型,但它给了我这个错误:
指定的成员映射无效."MyProject.MyEntity"类型中成员'MyPropertyHere'的类型'Edm.DateTimeOffset [Nullable = False,DefaultValue =,Precision =]'与'SqlServer.datetime不兼容[Nullable = False,DefaultValue =,Precision = 3] '成员'MyColumnName''类型'MyDataModel.Store.MyEntity'.
(基本上认为DateTime与DateTimeOffset不兼容.)
Web API OData团队真的只是遗漏了需要使用SQL Server类型的所有人DateTime吗？
更新:我找到了相关的解决方法,但他们需要更新EF模型才能使用它们.如果我能避免,我宁愿不必单独更新几百个属性.
更新:这个问题让我意识到微软管理其OData产品的方式存在很大的缺陷.有很多问题,但这个问题最为明显.Web API OData中存在巨大的缺失功能. 插件的交易和排序是其中两个.这两个项目(在OData规范中并且在Microsoft杀死它之前在WCF数据服务中)对于任何真实系统都是至关重要的.
但是,他们决定花时间去删除对许多开发人员非常有用的功能,而不是将时间放在那些缺少OData规范功能的关键位置.它体现了糟糕的管理,以便在添加急需的功能时优先删除工作功能.
我尝试与Web API OData代表讨论这些问题,最后,我打开了一个问题/票证,几天后关闭了.那是他们愿意做的结束.
正如我所说,Web API OData的管理还有很多问题(与DateTime无关,所以我不会在这里列出). 我一直是OData的坚定支持者,但Web API OData管理层的明显问题迫使我和我的团队/公司放弃了它.
幸运的是,可以设置普通的Web API以使用OData语法.设置控制器的工作量更大,但最终工作得很好.它支持DateTime.(并且似乎管理层至少可以远离制定疯狂的错误决策.)