实体框架中 ProviderManifests 的向后兼容性

Question

EntityFramework 使用的 ProviderManifest 是否向后兼容，尤其是对于 Oracle 和 SQL Server？

我正在创建一个 DbProviderInfo 类的实例以传递给 DbModel.Build()。构造函数的第二个参数是 ProviderManifestToken。

正如documentation 所说，ProviderManifestToken 是：

一个字符串，用于标识正在使用的数据库服务器的版本 用过的。例如，SQL Server 提供程序使用字符串“2008”作为 SQL Server 2008。这不能为空，但可以为空。

有一个相关的、未回答的问题here 询问 ProviderManifestInfo 的作用。通过阅读this page，我了解到它允许数据库提供程序确定返回哪个版本的 ProviderManifest，而无需使用数据库连接。 （最后一个链接也解释了 ProviderManifest 的作用。）

在实验中，我发现我可以毫无问题地使用 ProviderManifestToken 为“11.2”的 Oracle 12 数据库。但这一般应该是真的吗？例如，如果我将“2008”作为 ProviderManifestToken 传递，并且我使用的是 SQL Server 2012，我可以期望“事物”正常工作吗？

我一直无法找到关于这一点的任何文档，如果供应商之间的情况有所不同，我不会感到惊讶。

Answer 1

但这一般应该是真的吗？例如，如果我将“2008”作为 ProviderManifestToken 传递，并且我使用的是 SQL Server 2012，我可以期望“事物”正常工作吗？

是的，取决于数据库提供者的向后兼容性。至少，Oracle 和 SQL Server 非常不愿意在新版本的数据库中破坏现有应用程序，因此为旧版本编写的应用程序通常可以正常工作。

ProviderManifestToken 的主要目的是允许 EF 为数据库提供程序使用新功能，而不会放弃对旧版本的支持。例如，SQL Server 在 SQL 2012 中引入了 OFFSET .. FETCH 分页。如果没有 ProviderManifestToken，EF 将不得不在使用旧的查询表单进行分页（基于 ROW_NUMBER()）或放弃对 SQL 2008 的支持之间做出选择。

EF 可能会生成在更高版本上无法正常工作的查询，这将是 EF 中的一个错误。但我不知道有这样的案例。