Backwards compatibility of ProviderManifests in Entity Framework

Question

Are the ProviderManifests used by EntityFramework backwards compatible, in particular for Oracle and SQL Server?

I'm creating an instance of the DbProviderInfo class to pass to DbModel.Build(). The second argument to the constructor is the ProviderManifestToken.

As the documentation says, the ProviderManifestToken is:

A string that identifies that version of the database server being used. For example, the SQL Server provider uses the string "2008" for SQL Server 2008. This cannot be null but may be empty.

There is a related, unanswered question here asking what ProviderManifestInfo does. From reading this page I understand that it allows the database provider to determine which version of the ProviderManifest to return, without using a database connection. (What the ProviderManifest does is also explained at that last link.)

Experimentally, I have found that I can use an Oracle 12 database with a ProviderManifestToken of "11.2" with no problems. But is this supposed to be true in general? For example, if I pass "2008" as the ProviderManifestToken and I am using SQL Server 2012, can I expect 'things' to work OK?

I have been unable to find any documentation on this point and I would not be surprised if things are different from provider to provider.

Answer 1

But is this supposed to be true in general? For example, if I pass "2008" as the ProviderManifestToken and I am using SQL Server 2012, can I expect 'things' to work OK?

Yes, subject to the backwards-compatibility of the database provider. Oracle and SQL Server, at least, are very reluctant to break existing applications in new versions of the database, so applications written for older versions typically work fine.

The main purpose pf the ProviderManifestToken is to allow EF to use new functionality for a database provider, without abandoning support for old versions. For instance SQL Server introduced OFFSET .. FETCH paging in SQL 2012. And without the ProviderManifestToken EF would have to choose between using the older query form for paging (ROW_NUMBER() based), or drop support for SQL 2008.

It is possible that EF would generate a query that doesn't work correctly on a later version, which would be a bug in EF. But I don't know of any such cases.